← BlogKey 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.

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.

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