App Check 403 error due to ReCAPTCHA rejections especially in incognito mode

[anisabboud]

Operating System

Windows 11, iPhone

Environment (if applicable)

Chrome 138, Safari

Firebase SDK Version

11.9.1

Firebase SDK Product(s)

AppCheck

Project Tooling

Angular 20.0.4 (latest) @angular/fire 20.0.1 (latest) firebase 11.9.1 (latest)

AppCheck is initialized in app.config.ts via:

import { ReCaptchaV3Provider, initializeAppCheck, provideAppCheck } from '@angular/fire/app-check';

    provideAppCheck(() => initializeAppCheck(getApp(), { provider: new ReCaptchaV3Provider(recaptcha3SiteKey), isTokenAutoRefreshEnabled: true })),

No changes have been made to this configuration since 2023 aside from updating dependencies (and we don't actively/explicitly show "Captcha" to the user).

Detailed Problem Description

Recently many users are reporting issues loading our webapp, stemming from an AppCheck throttling error (which blocks access to Firestore).

Console error

POST https://content-firebaseappcheck.googleapis.com/v1/projects/<projectId>/apps/<appId>:exchangeRecaptchaV3Token?key=<apiKey> 403 (Forbidden)
@firebase/app-check: AppCheck: 403 error. Attempts allowed again after 01d:00m:00s (appCheck/initial-throttle).
@firebase/app-check: AppCheck: Requests throttled due to previous 403 error. Attempts allowed again after 01d:00m:00s (appCheck/throttled).

Network tab

{ 
  error: {
    code: 403, 
    message: "App attestation failed.",
    status: "PERMISSION_DENIED"
  }
}

I suppose this error is meant to show up to "bots", but recently it's occuring to real users too frequently. Perhaps something changed on the AppCheck server side that made it too strict?

Steps to reproduce issue

1. Close all incognito windows (important)
2. Open a new Chrome incognito window
3. Go to https://www.brainko.com and wait 5 seconds for the site to load
4. Open Chrome DevTools console (Ctrl + Shift + J)
5. You should see the errors above (POST 403 App attestation failed followed by appCheck/initial-throttle error, followed by appCheck/throttled, followed by failing requests to Firestore...)
6. If you don't see the error, close all incognito windows and try again a few times

Notes

Note 1: This might be related to recent changes by @hsubox76 in March 2025 (PR https://github.com/firebase/firebase-js-sdk/pull/8842, commit https://github.com/firebase/firebase-js-sdk/commit/95b4fc69d8e85991e6da20e4bf68d54d4e6741d6), which introduced the INITIAL_THROTTLE error.

Note 2: This might be related to https://github.com/firebase/firebase-js-sdk/issues/7371 which reported a similar issue two years ago but was closed by the bot without a resolution. Also related: https://www.reddit.com/r/Firebase/comments/1ivpaet/firestore_app_check_throttling_requests/.

Note 3: I've encountered the throttling error in incognito since June 2023 (two years ago) and assumed it's for protection against bots, but in the past week real users are reporting this issue (and they're probably not using incognito... I just used that for the reproduction.) There might be some changes in iOS privacy that are triggering this more frequently, or changes in AppCheck server.

Note 4: On iPhone, this is happening very frequently on Safari (not on private browsing), but not on Chrome. Also happens on iPhone when the webapp is installed as a PWA (added to home screen and opened as an app). Perhaps there were some recent privacy-oriented changes in how Safari behaves on iOS that the reCAPTCHA server needs to adapt to.

Note 5: Google reCAPTCHA admin console shows 36% "Suspicious requests" over the past 7 days, 22% percent "Suspicious requests" over the past 90 days (screenshot).

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[ivansalacceo]

I had the same issue with this setup:

Firebase SDK version: 11.9.1 OS: Mac Ventura 13.3 Browser: Brave & Chrome (v137.xx.xx), Safari (v16.4)

When I tried to switch ISP from home router to mobile data provider, it starts working. Not sure what am I missing.

[th0rgall]

We've also been experiencing a dramatic uptick in reCAPTCHA rejections in the last weeks, leading to this error and others.

We've received multiple user reports per day of a broken website that we could trace back to App Check throttling (most likely due to reCAPTCHA rejection). For us this trend seemed to start on June 16th, after which it escalated: it had reached almost 50% of sessions being rejected, which is why we unenforced App Check, since the mass rejection of legitimate users is unacceptable.

At first I assumed this issue was due to recent changes we had made, but I couldn't pinpoint anything by reverting changes. Finding this issue makes me think that another external changed factor in browsers or App Check/reCAPTCHA may be the cause. In @anisabboud's screenshot I can see that the most recent trend in rejections also started on June 16th.

Here are screenshots of our Google Cloud reCAPTCHA dashboard clearly illustrating the issue:

Risky vs safe graph: notice how "risky" becomes almost as prevalent as "safe"

Classification of issues

More context:

• We migrated to reCAPTCHA Enterprise in Nov. 2024 after Google's recommendation, so we're not using reCAPTCHA v3 as opposed to the opening post here. Hence, our dashboard looks different.
• For us App Check/reCAPTHA had also been mostly working fine for the last years, except for reoccurring issues on Firefox on Android with Enhanced Tracking Protection switched on.
• We were on the JS SDK version 10.14.1 since October 2024. I only upgraded to 11.x two days ago (July 1st), in the hope that it would fix this issue (I noticed some App Check related changes in the changelog). It didn't change anything, so this might not have anything to do with the JS SDK version.
• We've seen issue reports from various browsers, both on desktop and mobile, and were able to reproduce them ourselves intermittently. I've seen it appear most often on an iPhone (Safari and Firefox) on the first load after our site had been inactive/not loaded for a day or so.
• We have a reCAPTCHA token expiration duration of 3 days (vs the default of 1 hour?)
• Workarounds we've seen that work sometimes: restarting browsers, clearing browser cache, changing from WiFi to cellular or vice-versa, refreshing the page 1 to 10 times...

Update July 7th: the error/rejection rate is still similarly high. I filed an issue in reCAPTCHA's internal issue tracker via this page (id: 429956185), linking back to this GitHub issue too.

[trullock]

Coming here to report the same problem.

There's definitely something up.

My site has too low traffic volumes to produce meaningful graphs, but its been working for a year and ive started getting evidence of this in the last week or so.

Firebase doesn't seem to work at all in Incognito, presumably becuase of 3rd Party cookie settings or something...

[yuvalhermelin-fijoya]

We are also experiencing this. Any updates from the firebase team? App check worked perfectly for a long time and all of a sudden in last 1-2 weeks we are getting lots of errors as described above, replicated in the same way.

[SherpaMiguel]

We are also experiencing the issue. It is a nightmare for us.

[josiahsrc]

Same issue

[hsubox76]

It's very complicated to pinpoint the cause of these errors, and a lot of different problems can lead to similar-looking errors, so to help all of us try to figure it out I should probably provide some background.

Background

These are the steps that happen when validating with Firebase App Check:

1. The attestation provider (ReCAPTCHA in most cases, since we provide that out of the box, although you can create your own CustomProvider) runs checks to validate the user is valid. How ReCAPTCHA runs this check and what it is looking for is a black box to the user, to you the developer, and to us, the Firebase team. (The SDK might throw an error that says "ReCAPTCHA error." if there's something wrong at this point and it can't even run the ReCAPTCHA script.)

2. ReCAPTCHA encodes its findings (whether you are a valid or invalid user) into a string (that you can't interpret on the client side), and the Firebase SDK sends this string to the App Check Exchange endpoint.

3. The App Check server gives that string to a ReCAPTCHA backend service which interprets the score (were you a valid or invalid user) and tells the App Check server. If it was a good score, the App Check server then creates a valid App Check token and sends it back to the Firebase SDK. If it was a bad score, it doesn't send a token back.

4. If it received a valid App Check token, the Firebase SDK, attaches that token to the requests of products that use App Check (Firestore, Auth, etc.).

5. Shortly before the TTL of the token expires (you can set this in the Firebase Console), the Firebase SDK will try to refresh and get a new token. It will follow all the steps above, starting with ReCAPTCHA trying to evaluate the environment and see if the user is valid. If the computer/browser/tab is in some unusual state at this point, this may lead to ReCAPTCHA evaluating the user as invalid, and the subsequent steps failing.

If there's an error during the request in step 2-3, if the App Check Exchange server returned an HTTP status error code (something other than 200), what the Firebase SDK does depends on the error code.

1. If it is 404 or 403 (attestation failed, wrong API key, project deleted, etc.) - it will set a 24 hour backoff before trying again, because a retry is unlikely to fix the problem.

2. If it is another code (such as 501), where the server might be having issues, a retry might fix the problem, so it will retry repeatedly after a much shorter time (exponential backoff starting with about 1 second).

A lot of failures while the computer/browser/tab is inactive are likely caused by ReCAPTCHA evaluating you as an invalid user while in that state and causing the 24 hour backoff.

Solutions

Common sense seems to say that being evaluated as an invalid or suspicious user simply because your computer is asleep/backgrounded/incognito is not very fair, and shouldn't force a 1 day freeze on any subsequent requests. This makes sense but we don't have any way to tell if you are in one of those states. I added the "Recaptcha Error" error to at least tell us if some unusual state is prevent ReCAPTCHA from working at all, but it won't tell you if ReCAPTCHA is working and has simply evaluated you as a suspicious user.

Other than that, the only info we get is the HTTP status error code that may indicate attestation failed. It might be an "unfair" attestation failure or a genuine one due to a suspicious user. ReCAPTCHA can't distinguish so we can't distinguish. So we add the 1 day backoff to prevent abuse if an actual suspicious user is spamming your app.

If there was a way to detect all "problem cases" like when the computer is asleep, backgrounded, etc. and when the user returns, we could postpone doing any getToken activities when the user comes back. Unfortunately it seems like there are a lot of cases and a lot of them are not detectable.

Diagnosis

I would suggestion pinpointing the issue to see if it's an issue with ReCAPTCHA itself versus something that can be fixed in the Firebase SDK code. If it's an issue with ReCAPTCHA, we (the SDK team) are not able to fix it. We can try to escalate it but they would probably be more responsive to direct communication from customers.

In order to do this, set up a simple test app that does not use Firebase and only uses ReCAPTCHA. Here's some instructions for ReCAPTCHA Enterprise: https://cloud.google.com/recaptcha/docs/create-assessment-website

You'll need to set up a web page which loads ReCAPTCHA and also need to check the resulting assessment from a server or from your local dev machine with credentials.

If this keeps giving low scores from the machines/environments/circumstances you are seeing App Check failures on, then the problem is with ReCAPTCHA's behavior regarding your environments and not something we can change in the SDK, and you may want to discuss this with ReCAPTCHA support or trying a different provider (see Workarounds below).

Unfortunately we don't know the reason behind individual ReCAPTCHA scores and so we're not able to handle an "unfair" false positive ReCAPTCHA assessment differently from a real suspicious user.

Workarounds

If ReCAPTCHA's behavior is causing the problem for you, you may want to try another attestation provider, which you can set up using our CustomProvider class.

Conclusion

Having read all that, if you have any suggestions about how the SDK could better handle this, given that we can't distinguish between ReCAPTCHA false positives and actual suspicious cases, let us know your suggestions.

If you have diagnosed that your problem is a high rate of ReCAPTCHA false positives, I would suggest contacting the support team that covers ReCAPTCHA.

[anisabboud]

Thank you for the attention to this issue and for the detailed response, @hsubox76.

Seeing as multiple projects in this thread have recently experienced a surge in AppCheck errors for real users, perhaps you guys could check with the ReCAPTCHA team to ask if they've had any similar recent reports or if they've noticed any changes in their logs, etc.

I could understand why visiting the site from incognito could be interpreted as bot (not enough history/context to attest that this is a real user), though maybe that's something that could be solved through coordination with the the Chrome team so that they could supply the right signals for reCAPTCHA even in incognito.

But one user reported that they've repeatedly encountered the issue on their iPhone with latest iOS 18 when they install our Angular webapp as a PWA. The site works fine for them on Safari, but as soon as they "install" it ("Add to Home Screen") and open it via the app icon, they get 403. Perhaps something recently changed in WebKit sandboxing on iOS (that makes PWAs behave as if the user is in "private browsing" / incognito), requiring some attention / algorithm update from the reCAPTCHA team.

Aside from consulting with the reCAPTCHA team, is there a good way to for us to catch these errors so that we could maybe prompt the user to reload the page? (e.g., where in my code could I add a handler to catch the 403 error when using AngularFire?)

[trullock]

I can readily repro this in Chrome Incognito

		initializeAppCheck(app, {
			provider: new ReCaptchaV3Provider(recaptchaKey),
			isTokenAutoRefreshEnabled: true
		});

The URL this calls returns a 403 with

{
  "error": {
    "code": 403,
    "message": "App attestation failed.",
    "status": "PERMISSION_DENIED"
  }
}

From thereon nothing works because AppCheck isnt set up properly

I appreciate everything @hsubox76 has said, but.... what next?

My app did work and now it doesn't. Somethings changed.

My only solution is to turn AppCheck off, because its currently unusable

[trullock]

At the very least can we make initializeAppCheck return something useful instead of swallowing all the errors, then we can at least detect this and have the UI tell the user not to use Firebase

Edit

OK, so getToken throws, we can detect it like this

		let appCheck = initializeAppCheck(app, {
			provider: new ReCaptchaV3Provider(recaptchaKey),
			isTokenAutoRefreshEnabled: true
		});
		getToken(appCheck, false).then(t => {
			console.log(t)
		}, e => {
			if(e.name == 'FirebaseError' && e.code == 'appCheck/initial-throttle')
			console.error(e)
		})

[yuvalhermelin-fijoya]

We are getting UNEXPECTED_ENVIRONMENT for incognito - reproducing 100/100..

[th0rgall]

@trullock the getToken call is exactly what we did as well to detect the issue. We are logging these errors to our analytics service, which is another way for us to track how often this happens (still equally often).

At the very least can we make initializeAppCheck return something useful instead of swallowing all the errors

This was already discussed in this issue https://github.com/firebase/firebase-js-sdk/issues/8822, and it looks like the Firebase team doesn’t want to throw errors from the initializeAppCheck call. It would be a significant breaking change, since a ReCAPTCHA rejection or config issue might then block your Firebase init code even when App Check enforcement is turned off.

@hsubox76

Trying a Custom Provider

If ReCAPTCHA's behavior is causing the problem for you, you may want to try another attestation provider, which you can set up using our CustomProvider class.

I have tried Cloudflare Turnstile as an alternative in a staging environment. I made my own Turnstile App Check custom provider with their “implicit rendering” flow, because their default “explicit rendering” implementation caused this issue (only on iOS & macOS, which is potentially interesting considering my iOS remarks further down here).

From my limited testing, Turnstile did not exhibit the same issues as ReCAPTCHA, pointing to a ReCAPTCHA issue, and not an App Check issue. I haven’t published it in production yet.

Trying a ReCAPTCHA test app

In order to do this, set up a simple test app that does not use Firebase and only uses ReCAPTCHA.

I just did this too, but I’m not sure how helpful it is. As far as I know/can find, the default Firebase App Check/ReCAPTCHA Enterprise integration always uses a score-based ReCAPTCHA key, and it is not publicly known which cutoff score or assessment reasons are used to consider a client invalid by Firebase services.

So, even though I can do testing on a demo site with some of the devices/browsers that have issues on our production site, I don’t know whether App Check would reject them based on the score.

On my super basic test site (just one button that executes a challenge), I’m always getting scores like 0.8999999761581421…. on whatever incognito/private browser I use. The reasons always include LOW_CONFIDENCE_SCORE.

After some minutes of inactivity on a private tab in browsers on iOS (Safari, Firefox) and a re-assessment, I’ve also seen TOO_MUCH_TRAFFIC and UNEXPECTED_ENVIRONMENT (but still with a score of 0.899999...). I relate this to your comments about ReCAPTCHA’s known issues with inactive/background sites, but I can't reproduce this on desktop browsers.

I guess this constant high score still means I’m not able to reproduce the issue, unless App Check rejects assessments at a score of ≤0.9.

More observations

Related to the link to background/inactive/incognito browsers:

• Most App Check/ReCAPTCHA issues in the recent uptick still occur on iOS for us.
• We also encourage users to add our site as a PWA Home Screen App on iOS, like the opening post, but I can’t tell yet if those constitute the main share of affected iOS devices.
• I’ve personally seen the issue also in non-incognito and non-iOS contexts. One more hypothesis: as part of the PWA, we use a service worker to load cached HTML & JS assets for our SPA. Might this influence ReCAPTCHA’s assessment of the “freshness” of the page? Are any of the other affected sites here using service workers?

Having read all that, if you have any suggestions about how the SDK could better handle this, given that we can't distinguish between ReCAPTCHA false positives and actual suspicious cases, let us know your suggestions.

Am I correct in assuming that if I want to control/change the ReCAPTCHA cutoff score myself, I need to re-implement the ReCAPTCHA App Check provider myself, and use my own backend endpoint?

Making this easier or more configurable would be great.

[anisabboud]

Additional context

In addition to incognito, this is happening to users on Safari on Mac as well as Safari on iOS (especially when installing the webapp as a PWA via "Add to Home Screen"), in particular for users who pay for iCloud subscription and thus have Apple's Private Relay turned on (similar to VPN).

https://support.apple.com/en-us/102602 https://support.apple.com/en-us/guide/icloud/mm7dc25cb68f/icloud

iCloud Private Relay — part of an iCloud+ subscription — helps protect your privacy when you browse the web in Safari.

When Private Relay is enabled, your requests are sent through two separate, secure internet relays.

• Your IP address is visible to your network provider and to the first relay, which is operated by Apple. Your DNS records are encrypted, so neither party can see the address of the website you’re trying to visit.
• The second relay, which is operated by a third-party content provider, generates a temporary IP address, decrypts the name of the website you requested, and connects you to the site.

Most of our users are using iPhone, and we can't just tell them that this is not fixable because reCAPTCHA is a black box... This is a critical issue blocking access to the database for real users.

Could you please check with the reCATPCHA team how requests coming through Private Relay are handled and what can be done on their side to resolve this issue?

Perhaps these requests are being flagged as bots by reCAPTCHA because everyone using Private Relay would be redirected through similar IPs (the IPs of the Private Relay content provider servers). If so, perhaps these IP ranges could be whitelisted as Apple Users, etc.

See a related guide from Apple: https://developer.apple.com/icloud/prepare-your-network-for-icloud-private-relay/

[ian-sayles]

I have been having these "FirebaseError: AppCheck: 403 error" on my Mac using Safari, and also I have Private Relay. It also does not work on my iPhone.

But what is strange I can access the same web app using Chrome or Firefox on my Mac and it works perfectly.

[trullock]

What are the risks in disabling AppCheck? Given thats the only option at the moment because it's completely unusable.

What attacks am I at risk from?

CSRF and similar session jacking type attacks?

[yuvalhermelin-fijoya]

Even IF this is being taken seriously by the team at firebase SDK and/or reCAPTCHA team - it is annoying that we are not getting constant communication in this thread or in some other way regarding this. Seems like this is a widespread issue and its effect is very serious on apps and their users.

Can we please get an update from someone on the team guys?

[yuvalhermelin-fijoya]

What are the risks in disabling AppCheck? Given thats the only option at the moment because it's completely unusable.

What attacks am I at risk from?

CSRF and similar session jacking type attacks?

Also joining this question if anyone with some expertise on this (or the sdk team by chance) can elaborate 🙏

[yuvalhermelin-fijoya]

@hsubox76 Given that you replied to this thread already (and thank you for that) - I feel like its ok to tag you directly (as you are part of the conversation)

Please see the last messages since you last replied and hopefully help us out 🙏

[th0rgall]

As far as I understand it, App Check & ReCAPTCHA are mainly intended to block bots/non-human agents from accessing your Firebase resources. That means automated data scrapers, spam bots, but also machines used for (D)DoS and EDoS/"billing" attacks.

Without App Check it is also easy for a 3rd party to connect directly to your Firebase services. For example, for an alternative front-end, or to run automations. Firebase doesn't enforce the HTTP Origin/Referer restrictions on its browser API keys without App Check (maybe it once did, but not anymore, I've tried).

That said, your Firestore Security rules are still an important layer of protection. If you make sure a single malicious user can't do something unintended, a bot can also not do it. I don't think disabling App Check poses any additional CSRF risks, but I'm no expert there.

[sukeshtedla]

Same issue has been affecting our apps on web.

[fachrezamuslim]

Same issue here. A couple of users have the same network provider, but some of them got the error.

For the users who got the error, the solution is to change the network provider.

[hsubox76]

We are trying to talk to all the teams involved internally and come up with some way to address the problem. We will report back as soon as we have anything new.

I changed the title of this issue (previously just had the error message "@firebase/app-check: AppCheck: 403 error. Attempts allowed again after 01d:00m:00s (appCheck/initial-throttle)" and said it happened too often in incognito mode) because I'm concerned that users may reply "same issue" due to just seeing the same error message.

The same error message may be caused by other issues so we want to keep this issue focused on errors likely caused be ReCAPTCHA rejections. It can be difficult to tell, but if it's failing for some users and not others, and can be fixed by the users trying a different provider or device, then it's probably an issue with ReCAPTCHA flagging users you don't want flagged. Another way to be sure it's ReCAPTCHA is if you try a plain ReCAPTCHA test (no Firebase) in environments you find most often affected and see a lot of low scores. I see in the comment above that we don't make clear what exactly the score threshhold is - we will look into if we can share that or even possibly make it configurable.

[trullock]

Thanks @hsubox76

How do we do the ReCAPTCHA test you describe?

It seems to me that ReCAPTCHA has been changed and either; they've "broken" the internal mechanism that's started reporting legitimate users as bots, and/or theyve changed the scoring and the Firebase threshold is now tripping for people it didn't do previously.

We really need a fix for this, as its killing our user base

[hsubox76]

Here's how to use ReCAPTCHA by itself to check your scores:

Diagnosis

I would suggestion pinpointing the issue to see if it's an issue with ReCAPTCHA itself versus something that can be fixed in the Firebase SDK code. If it's an issue with ReCAPTCHA, we (the SDK team) are not able to fix it. We can try to escalate it but they would probably be more responsive to direct communication from customers.

In order to do this, set up a simple test app that does not use Firebase and only uses ReCAPTCHA. Here's some instructions for ReCAPTCHA Enterprise: https://cloud.google.com/recaptcha/docs/create-assessment-website

You'll need to set up a web page which loads ReCAPTCHA and also need to check the resulting assessment from a server or from your local dev machine with credentials.

If this keeps giving low scores from the machines/environments/circumstances you are seeing App Check failures on, then the problem is with ReCAPTCHA's behavior regarding your environments and not something we can change in the SDK, and you may want to discuss this with ReCAPTCHA support or trying a different provider (see Workarounds below).

I am looking into our internal handling of scores and what we can do.

[yuvalhermelin-fijoya]

@hsubox76 What's the update on this please?

Thanks!

[yuvalhermelin-fijoya]

@hsubox76 ??

[SherpaMiguel]

This is a critical issue and makes App Check unusable in production environments. We use the complete Firebase stack, except for Firebase App Check.

[trullock]

Google stopped caring about Firebase long ago. Between this, the various deployment issues, terrible support, broken rewrite rules, dodgy websocket stack its time to move on.

[yuvalhermelin-fijoya]

@hsubox76 and/or other firebase team member, please reply to this thread with updates - it is becoming very unprofessional to ignore this thread for 2 months after first reply.