Firebase config present (rules unverified)

What this means

This check is informational. It fires when your bundle contains a Firebase web config, which tells us your app talks to Firestore or Firebase Storage directly from the browser. The config itself is public by design and is not a leak. What we cannot see from the outside is whether your security rules let anonymous callers read or write.

How we test it

We fetch the home page and its first-party bundles and look for the shape of a Firebase web config: an apiKey beside a projectId and a Firebase app domain. If we find one, the check reports info with the project id as evidence and never fails on its own. We make no request to Firebase, Firestore or Storage at all; rules cannot be judged passively.

Why it matters

Open Firestore or Storage rules are the Firebase form of RLS off. With the config in page source, every visitor holds the same client the app uses, so the rules are the only thing between them and your data. Module 3's rule 6 applies unchanged: the public key is public, the database must refuse it by default, and every opening needs a rule you can read.

The fix

Open your project's Firestore and Storage rules in the Firebase console and make the default deny, with a read or write allowed only for signed-in users on the documents and paths they own. Treat it exactly as Module 3 treats row level security: locked by default, each opening justified and written down, verified afterwards with one anonymous request that returns a permission error. The full runbook is in the Fix Kit, Module 03.

Prompt for your AI

Paste this into the coding agent that built the app. It reproduces the finding and stops before changing anything; the fix steps are in the kit.

Find the Firebase web config in the built bundle and print the projectId and the storage bucket name. Print nothing else from it.
Search the source for every Firestore collection name and Storage path the app reads or writes and list them.
Read the rules files in the repo (firestore.rules and storage.rules if present) and quote every allow statement.
Flag any rule that allows read or write without a signed-in user, and any rule that opens a whole collection or the bucket root.
Do not change any rule and do not deploy anything; list what it would take to close each open rule and stop.
Run: grep -c "if true" firestore.rules storage.rules 2>/dev/null and show me the output; expected: 0 for each file.