Firebase config issues on Firebase
Your Firebase config is in your client code. That is normal and intended — the config (apiKey, authDomain, projectId) is public by design. It becomes a problem only if your Firestore or Storage rules allow broad access, OR if you are using the Admin SDK credentials (a service account JSON) client-side. Check which one you have, and fix the rules or rotate the service account accordingly.
The fix for Firebase
Web config — tighten rules
Confirm your Firestore and Storage rules require auth. See the firebase-rules-open fix guide.
Admin SDK credentials leaked
In GCP console, revoke the service account. Create a new one. Store the JSON in your backend server env, never in client code.
Restrict the web API key
Optional defense in depth: in GCP console, go to APIs & Services → Credentials → Browser API key → Application restrictions → HTTP referrers. Add only your domains. This prevents the key being used from other sites.
Why it matters
The Firebase web config is often flagged as "leaked secrets" by security scanners, but the real risk is upstream — it is only a leak if the data it unlocks is accessible. The config plus wide-open rules is the critical issue.
Confirm the fix worked
Scan your Firebase site to confirm this finding is gone.
AI prompt
Apply across your codebase
Paste this into Cursor, Lovable, Bolt, v0, or Claude Code.
Check my site for Firebase configuration. Tell me whether what is exposed is the normal web config (apiKey, projectId — safe if rules are strict) or actual Admin SDK service account credentials (a real leak). If it is the web config, audit my Firestore and Storage rules to make sure they require auth. If it is Admin SDK credentials, tell me exactly how to revoke them in GCP console and what to rotate.FAQ
Frequently asked questions
- Is it OK for my apiKey to be in my HTML?
- Yes. The Firebase web apiKey identifies your project; it does not grant permissions. Permissions come from rules. The name "apiKey" is misleading.
- Should I use .env for Firebase config?
- You can, but there is no security benefit — the values end up in your bundle either way. Do it only for DX (switching between dev and prod projects).
Related fix guides
Fix these too
Firebase rules too permissive
Firestore rules that allow unauthenticated reads or writes leave your database open to anyone. Here is how to write rules that actually protect your data.
Read moreHardcoded API key in JS
Any secret in your client bundle is public. Here is how to find them, rotate them, and move the calls server-side.
Read moreExposed Supabase service key
The service role key bypasses all security in Supabase. If it is in your client code, an attacker has full database access. Here is how to find and fix it.
Read moreFree tools