App Check Gets Zero-Config Init in Firebase SDK 12.15

Firebase shipped JavaScript SDK 12.15.0 on June 16, removing one of App Check’s most repetitive setup steps: you can now call initializeAppCheck() without passing a provider at all.

Key Takeaways

• Zero-config App Check init lands in firebase@12.15.0 (June 16, 2026): omit the provider argument and the SDK auto-constructs a ReCaptchaEnterpriseProvider from the recaptchaSiteKey in your Firebase project config (JS SDK release notes).
• A companion bug fix resolves a race condition between Auth and App Check when both initialize reCAPTCHA Enterprise independently.
• Firebase CLI 15.22.0 (June 18) added apphosting:secrets:revokeaccess, the mirror of the existing grantaccess, which closes the IAM cleanup gap for App Hosting deployments.
• The zero-config path is a gradual rollout; all projects should have it by end of June 2026.

What changed in App Check setup

The previous setup for reCAPTCHA Enterprise required you to explicitly construct and pass a provider:

import { initializeAppCheck, ReCaptchaEnterpriseProvider } from 'firebase/app-check';

initializeAppCheck(app, {
  provider: new ReCaptchaEnterpriseProvider('6Abc123-your-site-key'),
  isTokenAutoRefreshEnabled: true,
});

From 12.15.0, if recaptchaSiteKey is present in the config object you passed to initializeApp(), the provider argument is optional:

import { initializeAppCheck } from 'firebase/app-check';

initializeAppCheck(app, { isTokenAutoRefreshEnabled: true });

Firebase reads the site key from the config and constructs ReCaptchaEnterpriseProvider automatically. The explicit form still works; this is additive.

The recaptchaSiteKey field appears in the Firebase config snippet automatically once you enable App Check with reCAPTCHA Enterprise in the console. If your config object predates that setup step, re-download it from Project Settings.

The same release also fixes a latent conflict: when Auth and App Check both initialize reCAPTCHA Enterprise, they previously raced to load the reCAPTCHA script. The fix makes them coordinate, eliminating the class of errors that surfaced as intermittent App Check failures right after sign-in.

App Hosting: secrets revocation is now in the CLI

Two days later, Firebase CLI 15.22.0 (June 18) shipped apphosting:secrets:revokeaccess (CLI release notes):

firebase apphosting:secrets:revokeaccess MY_SECRET --backend=my-backend

This removes the roles/secretmanager.secretAccessor IAM binding from the named secret for the backend’s service account — the operation that was previously a manual step in the GCP console. The existing grantaccess command adds that binding when you wire a secret into apphosting.yaml; revokeaccess cleans it up when you remove the secret. Without this, a service account retains read access to secrets you’ve removed from the config.

The same CLI release updated the Pub/Sub emulator to v0.8.33 and the Data Connect emulator to v3.4.12, and fixed a non-deterministic file ordering bug when the Data Connect compiler processes multiple GQL source files.

What to do

Update to firebase@12.15.0 now. If your Firebase config includes recaptchaSiteKey, your App Check init can drop the explicit provider argument. If you use App Hosting and have removed secrets from apphosting.yaml without revoking IAM access, run firebase apphosting:secrets:revokeaccess against each one.