A Firebase API key used only with Firebase services is normally public by design, not a leaked secret. It identifies the Firebase project or app; it does not authorize database or storage access by itself. Verify that the key is restricted to the intended Firebase APIs, and review Firebase Security Rules and App Check instead of relying on the key being hidden.
This answer does not apply to every Google API key or every credential in a Firebase project.
What Firebase says the key does
Firebase’s current API-key documentation separates identification from authorization:
- the API key routes requests to the project and associates them with quota and billing;
- Google Cloud IAM, Firebase Security Rules, and App Check provide the relevant authorization and abuse boundaries;
- a Firebase-provisioned key restricted to Firebase-related APIs can be included in code and configuration;
- API restrictions and limits still matter.
That is why a web configuration like this is expected to be visible in the browser:
const firebaseConfig = {
apiKey: import.meta.env.VITE_FIREBASE_API_KEY,
authDomain: 'example.firebaseapp.com',
projectId: 'example',
storageBucket: 'example.firebasestorage.app',
appId: '1:1234567890:web:example',
}The configuration identifies the app and project. It is not the data-access policy.
Public Firebase configuration is not the same as a secret credential
| Value | Expected in a public client? | What protects the backend |
|---|---|---|
| Firebase web API key restricted to Firebase APIs | Yes | Security Rules, IAM where applicable, App Check, quotas |
| Project ID, auth domain, app ID, storage bucket name | Yes | They identify resources; they are not authorization secrets |
| Service-account private key | No | Privileged server credential; keep in a trusted server environment |
| Gemini Developer API key | No | Google explicitly says not to put it in code or configuration |
| A Google API key allowing unrelated billable APIs | Depends on that API and restrictions | Review the specific API’s authorization, application restrictions, API restrictions, and quota |
A generic scanner that reports every AIza... string as a confirmed credential leak misses this distinction.
The owner verification checklist
1. Identify the key
Open the Google Cloud console and go to APIs & Services → Credentials. Firebase says auto-created keys are commonly named:
Browser key (auto created by Firebase);Android key (auto created by Firebase);iOS key (auto created by Firebase).
For web apps, the matched value also appears in the Firebase config object’s apiKey field. Android and Apple apps use their platform configuration files.
Do not use a key found on a third-party site to discover what it can access. Verification belongs in the project owner’s console.
2. Review API restrictions
Confirm that the key is allowlisted only for the Firebase-related APIs the client needs. Firebase auto-provisions current keys with Firebase API restrictions, but owners should still review existing keys and environment history.
Do not add unrelated services to the public Firebase key merely because the app also uses them. Create a separate key with restrictions appropriate to that API.
Firebase explicitly warns that a Gemini Developer API key and the Generative Language API must not share the public Firebase key’s allowlist. Keep that credential server-side.
3. Review application restrictions and quotas
API restrictions answer which APIs accept the key. Application restrictions can constrain which websites, apps, or addresses may present it where the API supports those restrictions.
Test restriction changes in a non-production app before applying them to production. A restriction that is too broad may permit quota abuse; one that is too narrow can break legitimate clients.
If the project uses password-based Firebase Authentication, Firebase notes that a visible key can still be used to send authentication requests even when Security Rules protect data. Set authentication quotas to realistic traffic expectations and monitor abuse controls.
4. Review Firebase Security Rules
Security Rules protect Cloud Firestore, Realtime Database, and Cloud Storage data. Check the deployed rules, not only a local file.
For each collection, path, or bucket workflow, test:
- signed-out behavior;
- the intended signed-in user;
- a different user’s data;
- a different tenant or organization where applicable;
- protected field changes;
- create, read, update, and delete separately.
Rules that require only request.auth != null may authenticate the caller without enforcing ownership or tenant scope.
5. Review App Check
App Check helps supported backend resources distinguish requests from an attested app. It is an abuse-reduction layer, not a replacement for user authentication or Security Rules.
Record which products enforce App Check, which clients are enrolled, and what happens to older or unsupported clients before enabling enforcement.
When should you rotate or replace the key?
Do not rotate a correctly restricted Firebase client key solely because a visitor can see it. Rotation does not fix permissive Security Rules.
Replace or remediate the key when owner-side evidence shows that it:
- authorizes non-Firebase APIs that should not be available to the public client;
- lacks appropriate restrictions for its actual use;
- belongs to the wrong project or environment;
- was reused as a credential for a service where the key itself grants sensitive access;
- includes a service such as the Gemini Developer API that requires a protected key.
The remediation may involve separating services onto different keys, applying restrictions, updating the clients, tightening quotas, and reviewing usage during the exposure window. The correct response depends on the APIs the key actually authorizes.
What a visible Firebase key proves
It proves that the client has a project identifier required by Firebase services. It does not prove:
- that Firestore, Realtime Database, or Storage is public;
- that Security Rules enforce ownership or tenant isolation;
- that App Check is enabled or enforced;
- that the key is restricted to Firebase APIs;
- that password-authentication abuse controls match expected traffic.
A public-surface finding should therefore separate the observation from the unknowns.
Evidence-first result states
- Informational: a Firebase client key and public config appear in the browser, with no public evidence that the key authorizes a secret-only service.
- Needs verification: a Google API key is public, but its API restrictions and project role cannot be established from public evidence.
- Confirmed: owner-side configuration shows that a public key authorizes a service that requires a protected key, or deterministic authorized testing confirms an access-control failure.
- Not tested: Firebase Security Rules, App Check enforcement, tenant isolation, and authenticated role behavior were not assessed.
What the free scan can tell you
The free scan can identify Firebase configuration in referenced public assets, report its redacted location, and avoid calling it a leak solely because it is visible. It does not use the key, query Firestore, test Storage, submit authentication requests, or inspect the owner’s API restrictions.
What requires source or human review
Security Rules, Cloud Functions, IAM, callable endpoints, custom claims, tenant boundaries, and account-recovery workflows require owner access, source, or bounded authorized testing. Complex cross-user and cross-tenant rules benefit from a scoped Human security review.
For the same public-versus-privileged distinction in another backend platform, read Supabase API keys: publishable vs secret, anon vs service_role.
Limitations
“Firebase API key” is not a universal classification for every Google API credential. Review the actual API allowlist and the documentation for each enabled service. Firebase and Google Cloud console behavior changes over time; this guide reflects documentation reviewed on 2026-07-27.
Revision history
- 2026-07-27: Initial draft based on Firebase’s current API-key, restriction, Security Rules, and App Check guidance.