Is your Firebase API key safe to expose?

Every Firebase web app has a config object like the one below. None of it is secret. The apiKey is a Google Cloud API key that tells Google which project a request belongs to. It doesn't grant access to any data by itself, and Firebase's own documentation says a key restricted to Firebase services is fine to include in your code.

const firebaseConfig = {
  apiKey: "AIza...",
  authDomain: "your-app.firebaseapp.com",
  projectId: "your-app",
  storageBucket: "your-app.appspot.com",
  messagingSenderId: "1234567890",
  appId: "1:1234567890:web:abc123",
};

So when a scanner or GitHub alert says your Firebase key is exposed, that is usually expected for this key. What matters is what your Security Rules and sign-in settings allow a stranger to do once they have it.

• Security Rules for Firestore, Realtime Database and Cloud Storage. Every request from a client is checked against them. Rules created in test mode let anyone read and write until a date, and a rule of allow read, write: if true does it forever.
• Authentication settings. If email and password sign-up is enabled, anyone with your config can create an account through the Auth API, even if your app has no sign-up page. Rules that only check request.auth != null therefore let in any stranger who makes an account.
• App Check. It attests that requests come from your real app (reCAPTCHA Enterprise or reCAPTCHA v3 on the web) and, once you enforce it per service, rejects requests that don't. It raises the cost of scripting against your backend. It doesn't replace rules.
• API key restrictions. Keys Firebase creates are limited to Firebase related APIs, so check yours still is, and never add the Gemini API to a key that ships in your front end. You can also limit the browser key to your domains in Google Cloud Console, but Firebase calls several Google APIs behind the scenes, so restrict carefully and test sign-in afterwards.

Rules should check ownership, not just sign-in:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Test changes with the Rules Playground in the Firebase console before you publish them. Our scan can't read your rules or your database; it only sees what your site sends to a browser. If it finds an AIza key in your code, it flags the key so you can confirm it's restricted. It can't see the restrictions itself.

• Service account keys: a JSON file with a private_key field, used by the Admin SDK. Admin access skips Security Rules entirely.
• Any third-party key your Cloud Functions use, such as Stripe or OpenAI. Keep those in function secrets or server env vars.

A common AI-built mistake is an agent importing firebase-admin into client code, or dropping the service account JSON into src/ so an import works. The bundler then ships the private key to every visitor. The Admin SDK is for servers and Cloud Functions only. Our scan does flag private key blocks (BEGIN PRIVATE KEY) in your page and JavaScript.

1. In Google Cloud Console, open IAM and Admin, then Service Accounts, pick the account, open its Keys tab and delete the leaked key. That kills it immediately.
2. Only create a new key if you truly need one. Code running on Cloud Functions or Cloud Run can use the built-in service account without any key file.
3. Remove the JSON from your code and your git history, and redeploy.
4. Check Cloud Audit Logs for activity by that service account, look over your Firestore and Storage data for changes, and watch billing.

# 1. Put the leaked value in a file, one per line, mapped to a placeholder
echo 'PASTE_THE_LEAKED_KEY_HERE==>REMOVED' > replacements.txt

# 2. Rewrite every commit (work on a fresh clone, keep a backup)
git filter-repo --replace-text replacements.txt

# 3. Force push the rewritten branches, then delete replacements.txt
git push --force --all

For the web apiKey there's no emergency. If an unrestricted key is being used for quota you don't recognise, add restrictions, or create a new key, update your config, and delete the old one once the new build is live.