Firebase

Firebase rules for apps shipped by a builder

The Firebase web apiKey is not a secret. Realtime Database, Firestore, and Storage stay private only when their rules say so.

Updated 2026-10-27

The Firebase config object in a client app, including apiKey, authDomain, and projectId, is public by design. Security rules on Realtime Database, Cloud Firestore, and Cloud Storage are what stop a stranger from reading your data. A builder that scaffolds Firebase often leaves the test-mode rules in place so the first preview succeeds.

Test mode for Cloud Firestore is a pair of rules that allow read and write until a date, or a comment that says you will lock it down later. Test mode for Realtime Database is often .read and .write set to true at the root. Both are public. The date in a test-mode rule expires, but until it does the data is open, and a rule someone set to true without a date stays open.

Rules that match the product

Firestore rules should require request.auth != null for private documents, and then check that the signed-in uid owns the document. A rule of allow read, write: if true is a public database. A rule of allow read: if true is a public read, which is correct only for data you mean to publish.

Realtime Database rules are not Firestore rules. They live in a JSON tree. A parent .read: true overrides a stricter child. Lock the root, then grant access on the paths your app uses.

Storage rules should check request.auth and, for uploads, the content type and size. A default rule that allows public reads will serve every object URL.

Firebase App Check is an extra signal. It is not a replacement for rules. A modified client can still present a project apiKey. The rules engine is the enforcement point.

What a scanner can see without being you

A passive scan of the page can see the project id in the bundle. That is informational. It does not prove the database is open. An ownership-verified deep check may send a body-less request to the Realtime Database REST URL or the Firestore documents endpoint. If that request succeeds, the rules allowed an unauthenticated read. The scanner cancels any body and does not store documents.

If your rules are still in test mode, change them before you share the app URL. Then rotate any data you would not have posted in public, because an open rule means copies may already exist.

The Supabase RLS guide is the equivalent warning for Postgres. The Firebase apiKey and the Supabase anon key fail in the same way: they are identifiers, and the rules you attach to them do the work.

FAQ

Should I hide the apiKey in the Firebase config?

No. Google documents it as safe to ship. Restrict the key in Google Cloud if you want to limit which APIs it can call, and write security rules for the data.

Our rules require auth, but the scanner still says the database is open. What happened?

The check treats a successful response as open and a 401, 403, or 404 as closed. A success means some rule allowed that unauthenticated request. Read the deployed rules, not the draft in the console.

Does Firebase Auth being enabled lock the database?

No. Auth creates users. Rules decide whether a request with or without a user can touch a path.