Key leaked3 min readUpdated 2026-08-03

Firebase Admin key leaked: what to do

The Firebase apiKey in your frontend is fine. A service account JSON is the opposite of fine.

1. Rotate it now

Revoke and reissue in the Google Cloud console

  1. 1Open the Google Cloud console → IAM & Admin → Service Accounts, and select your project.
  2. 2Find the service account whose key leaked, open its Keys tab, and delete the exposed key.
  3. 3Create a new key and store the JSON somewhere only your server reads — never in the repository.
  4. 4Redeploy your backend with the new credentials.

Console: https://console.cloud.google.com/iam-admin/serviceaccounts

2. What someone can do with it

  • Full read and write access to Firestore and Realtime Database, ignoring every security rule you wrote.
  • Full access to Cloud Storage buckets in the project.
  • The ability to mint authentication tokens for any user — meaning they can act as any of your users, including admins.
  • Depending on the role attached, access to other Google Cloud resources in the same project.

3. Check whether it was already used

Look for activity you did not cause

  1. 1Google Cloud console → Logging → Logs Explorer, filtered to the service account and the period since exposure.
  2. 2Look for reads or writes from IP addresses that are not your infrastructure.
  3. 3Check Firebase Authentication for user accounts created outside your signup flow.
  4. 4Review your Firestore collections for unexpected documents or deletions.

Make sure the rules underneath are not open too

  1. 1Firebase console → Firestore Database → Rules. Look for allow read, write: if true or a bare request.time comparison left over from test mode.
  2. 2Open the Rules Playground and run a read against a user collection with authentication off. It should be denied.
  3. 3Repeat signed in as an ordinary user against a document owned by somebody else. Also denied.
  4. 4Check Storage rules separately — they are a different ruleset and the more commonly forgotten one.

This matters because the two problems compound. If the service account key leaked and your rules are open, revoking the key still leaves the database readable by anyone with your project ID — the emergency you came here for was only the louder of the two.

4. Find out how it leaked

Service account JSON files get committed because they arrive as a file rather than a string — serviceAccountKey.json lands in the project root and gets added with everything else. Check git history, not just your current files.

Paste this into Cursor, Claude Code or your builder
Find every hardcoded credential in this project and move it out of the code.

1. Search all files — including client code, config files, and anything
   already committed — for hardcoded secrets: Firebase / Google Cloud keys, plus
   any string starting sk-, sk_live_, AKIA, ghp_, or variables named
   *_SECRET, *_TOKEN, *_API_KEY.
2. For each one, tell me the file, the line, and whether that code runs in
   the browser or on the server.
3. Move every real secret to a server-only environment variable. Do NOT
   use a client-exposed prefix (VITE_, NEXT_PUBLIC_, REACT_APP_) — those
   are compiled into the browser bundle.
4. Any provider call that needs the secret must happen server-side; change
   the frontend to call my own endpoint instead of the provider directly.
5. Check whether the secret is in git history, not just the current files.
   If it is, say so — removing it from HEAD does not remove it from history.

Give me a list of every secret found, where it was, and what you changed.

Common questions

Is the Firebase apiKey in my frontend a leaked key?
No. The apiKey in your Firebase config is public by design — it identifies the project and grants nothing on its own. Finding it in your bundle is not an incident. A service account JSON is an entirely different object, and that one is a real emergency.
How bad is a leaked service account JSON?
It gives full read and write access to Firestore, Realtime Database and Cloud Storage while ignoring every security rule you wrote, and it can mint authentication tokens for any user — meaning the holder can act as any of your users, including admins.
I deleted the file from my repo. Is that enough?
No. Deleting a file does not remove it from git history, where it stays readable. If the JSON was ever committed, the key must be deleted in the Google Cloud console regardless of what your current files look like.
How do I know whether it was used?
Google Cloud console → Logging → Logs Explorer, filtered to that service account and the period since exposure. Look for reads or writes from IP addresses that are not your infrastructure, then check Firebase Authentication for accounts created outside your signup flow.

This is one check out of 40+

Paste your site address and we run the whole list from the outside — leaked keys, open databases, unprotected pages — then hand you one prompt that fixes what we find. Free, about 30 seconds, no signup.

Check my site — free