A Firebase project's client config (API key included) is meant to be public. That's not the risk. The real gap is Firestore, Realtime Database, and Storage security rules: Firebase's "test mode" starts every table wide open to any request for 30 days, and it's common for that permissive rule set to still be live long after the expiry date was meant to force a decision.
Why this happens in Firebase apps
Firebase bundles a database, auth, storage, and hosting behind rules you write yourself, which means the platform is only as locked-down as the rules you actually deployed, not whatever Firebase's dashboard defaults to when you started the project.
Test mode exists specifically to unblock early development without fighting rules syntax before there's anything worth protecting. The 30-day expiry is meant to force a real decision, but once an app is working, going back to write proper rules is easy to keep deferring.
Common issues in Firebase apps
What actually shows up in a Firebase project's configuration:
- Security rules left in test mode: Firebase's test-mode rules (allow read, write: if true) grant full public access and are meant to expire after 30 days, but a rule set copy-pasted or never revisited after that window can leave the exact same open access live indefinitely.
- Storage rules not scoped per-user: Cloud Storage for Firebase uses its own separate rules file from Firestore; it's common to lock down the database while leaving the storage bucket on a broader default.
- Callable Cloud Functions with no auth check: a Cloud Function callable from the client doesn't verify the caller's identity unless the function explicitly checks context.auth, an easy step to skip when the function only gets called from your own app's UI during testing.
- Web API key without HTTP referrer restrictions: Firebase's Web API key is safe to expose by design, but leaving it without HTTP referrer restrictions in Google Cloud Console means it can be used to call other Google APIs from outside your app if it's ever scraped for that purpose.
How to fix it
Firebase's own tooling covers most of this once you know where to look:
- Open Firestore/Realtime Database → Rules in the console and confirm you're not still on the test-mode default. Write rules scoped to auth.uid or specific document ownership.
- Check Storage → Rules separately; it does not inherit Firestore's rules and needs its own review.
- Add an explicit context.auth check (throwing an HttpsError if absent) to every callable Cloud Function that should require a signed-in caller.
- In Google Cloud Console → Credentials, add HTTP referrer restrictions to the Web API key scoped to your actual domain(s).
Frequently asked
If my Firebase API key is exposed in the frontend, is that a leak?
No. The Web API key is designed to be public and identifies your Firebase project, not a secret credential. The actual access control lives in your Firestore/Storage security rules, which is where the real risk sits.
How do I know if I'm still on test-mode rules?
Open Rules in the Firebase console for Firestore, Realtime Database, or Storage. Test-mode rules read as `allow read, write: if true` (or similarly unconditional) with an expiration timestamp comment. If you see that pattern past its expiry date, it's still live and open.