Firebase apiKey in your frontend is fine (and what isn't)
The apiKey in your Firebase config is public by design: it identifies your project so requests route to it, and Google's own documentation says it's fine to ship in code. What actually protects your data is your Security Rules, and the credentials that are dangerous to expose are the Admin SDK service account key and any key your code uses to call billable APIs like Gemini.
Applies to Firebase web and mobile appsSeverity depends what actually leakedDetected by static scan, no code execution
| the web config | admin credentials | |
|---|---|---|
| Looks like | apiKey: "AIzaSy…" inside firebaseConfig | A JSON file containing "private_key", or an AIza key that calls Gemini |
| What it is | An identifier that routes requests to your project | A credential that authenticates as your backend |
| What protects data | Security Rules, authentication, App Check | Nothing. It bypasses Security Rules entirely |
| If it leaks | Fine by design. Restrict the key, review your rules | Rotate immediately. Treat it as a breach |
| Where it belongs | Shipped to every browser and app build | Server env vars only, never in the repo |
Why the panic exists
Firebase API keys start with AIza, which makes them look exactly like a secret. Secret scanners flag them in every public repo, blog posts warn about them, and the finding spreads because it pattern-matches to a real problem. But the apiKey in a firebaseConfig block is not an access credential. It tells Google which project a request belongs to, the way a street address tells the mail where to go. It doesn't unlock the building.
This whole block ships to every visitor in every Firebase web app, by design:
What decides whether your data is safe is none of these values. It's your Firestore, Realtime Database, and Storage Security Rules, plus authentication and App Check. A project with strict rules and a visible apiKey is fine. A project with hidden config and rules set to allow-all is wide open.
What your apiKey actually lets someone do
Roughly what any anonymous visitor to your app can already do: send requests to your project that Security Rules then allow or deny. Copying the key out of your bundle doesn't grant a stranger any power your app wasn't already handing to every user. Two caveats are worth closing, though:
Unrestricted keys can touch other Google APIs
An API key with no restrictions isn't limited to Firebase services. It can be used against other Google APIs on your billing account. In the Google Cloud console, restrict the key to the services your app uses and pin it to your website or app bundle. That caps the blast radius without hiding anything.
Auth endpoints can be spammed
If email and password sign-in is enabled, the public auth endpoints can be abused for signup spam or password brute force. This is true for any app with public sign-up, key or no key. Tighten the authentication quotas and enable App Check so only your real app can talk to your project.
The Firebase credentials that are genuinely dangerous
The Admin SDK service account key
This is the one that ends up in breach reports. It's a JSON file, usually named firebase-adminsdk-….json, containing a private_key. It authenticates as your backend and bypasses all Security Rules. Committed to a repo, it hands full read and write access to your entire project to anyone who finds it:
If this file was ever committed, rotate it now: in the Google Cloud console, go to IAM, then Service Accounts, then Keys, create a new key and delete the compromised one. Deleting the file from your repo is not enough, because git history keeps every version.
Gemini and other billable API keys
Here's the trap for AI-built apps: keys for the Gemini API also start with AIza, and those are real secrets. Google is explicit that a Gemini key must never ship in client code. AI app builders love wiring Gemini calls directly into the frontend, which puts a pay-per-use credential in every visitor's browser. Same for Google Maps and any other billable API. The prefix can't tell you which kind of key you're looking at; what the key is used for can. If your code calls a billable API with it, it's a secret, and it belongs behind a server endpoint.
How to verify you're actually safe
private_key, BEGIN PRIVATE KEY, and firebase-adminsdk. Zero matches outside server-side env config.generativelanguage and other billable API endpoints in frontend files. Gemini calls belong in a server route, with the key in a server-only env var.allow read, write: if true on data that isn't meant to be public. This, not the key, is where Firebase apps actually get breached.If a security report's only critical finding is a visible Firebase apiKey, be skeptical of the whole report. That finding pattern-matched a prefix instead of reading the code. The questions that separate a real audit from noise: is there a private_key anywhere, do the Security Rules actually gate your data, and does client code call APIs that bill you per request?
Fair questions
Is it safe to expose your Firebase API key?
Yes. Google's own documentation says API keys for Firebase services are OK to include in code or checked-in config files. The apiKey identifies your project; it does not grant access to your data. Access is controlled by Security Rules, authentication, and App Check. The key being visible only becomes a problem when those rules are missing or wide open.
What can someone do with my Firebase API key?
Roughly what any anonymous visitor to your app can do: send requests that your Security Rules then allow or deny. Two caveats: an unrestricted key can be used against other Google APIs on your billing account, so restrict it, and public auth endpoints can be spammed if password sign-in is on, which quotas and App Check mitigate.
A scanner flagged an AIza key in my repo. Do I need to rotate it?
It depends what the key is for, because the AIza prefix is shared by very different keys. The apiKey in your firebaseConfig: no, restrict it and review your rules instead. A key that calls Gemini, Maps, or any billable API from client code: rotate it and move the call server-side. A file containing private_key: rotate immediately.
Should I restrict my Firebase API key?
Yes. Restrictions don't make an unsafe app safe, but they cap the blast radius. Limit the key to the Firebase services your app uses and pin it to your website or app bundle in the Google Cloud console. That stops the same key from being used against unrelated billable APIs on your account.
Which Firebase credentials must never be public?
The Admin SDK service account JSON (the file with private_key), which bypasses all Security Rules; keys for the Gemini API or other billable Google APIs; the legacy FCM server key; and the legacy database secret. All belong in server-side env vars only, and all require immediate rotation if they leak.
Ascertify is a static code audit for AI-built and agency-delivered apps. It reads your code without running it and reports what's exposed, what's missing, and what to fix first, in plain English, pinned to the exact file and line. Telling a public identifier from a real secret is exactly the judgment it applies to every key it finds; the free preview tells you how many real issues your code has.
Read-only access. Your code is sandboxed, never executed, and deleted after the scan.