Fix guide · info · firebase_project_exposed

Firebase project ID exposed in client

Why it matters

Firebase's web client config is public by design — it's printed in the Firebase Console and meant to ship in your bundle. The risk isn't the ID itself; it's everything you have to lock down separately for that ID to be safe: Realtime Database rules, Firestore rules, Storage rules, App Check, and (if you use them) the Auth sign-in providers. If any one of those is left at the default-prototyping setting, the project ID is the address an attacker uses to find it.

See firebase_rtdb_open, firestore_collection_public_read, and firebase_storage_public_list for the actual vulnerabilities.

How to fix it

There's nothing to fix about the project ID being in the bundle — that's correct behaviour. The work is auditing the surfaces it points at:

1. Realtime Database rules. Console → Realtime Database → Rules. Default is {".read": true, ".write": true} — this must be changed before launch. See /fix/firebase_rtdb_open.

1. Firestore rules. Console → Firestore Database → Rules. The "test mode" template grants public access for 30 days — and apps regularly ship that way. See /fix/firestore_collection_public_read.

1. Storage rules. Console → Storage → Rules. Same story as Firestore — test mode is open. See /fix/firebase_storage_public_list.

1. Enable App Check. Console → App Check. Adds a second layer (reCAPTCHA Enterprise / DeviceCheck / Play Integrity) that prevents non-browser callers from hitting your APIs even when rules permit them. Defence in depth.

Full guide: /blog/firebase-rules-vibe-coded.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.