How to fix exposed Firebase config with too-broad access
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.
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.
How to check
- 01Open your site source and find the Firebase initialization.
- 02If you see `firebaseConfig = { apiKey, authDomain, projectId, ... }` with only web keys, that is fine. Check your rules (see firebase-rules-open).
- 03If you see anything containing `type: 'service_account'` or `private_key`, that is the Admin SDK credentials — a real leak. Revoke immediately.
Or let SafeToShip check it for you in 60 seconds:
How to fix it
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.
AI prompt
Copy-paste into your AI tool
Paste this prompt into Cursor, Lovable, Bolt, v0, or Claude Code and it will walk through the fix for your specific codebase.
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
Check this yourself
Platform guides
Building on these platforms?
Firebase security
Firebase makes real-time apps easy, but misconfigured Firestore rules and open Storage buckets are the top security issues we find in Firebase projects.
Read moreLovable security
Lovable makes it easy to ship fast, but AI-generated backends often ship with open Supabase tables and leaked API keys. Scan your Lovable app before your users find out.
Read moreScan your site for this and 50+ other issues
Free scan. Results in 60 seconds. No account required.