Firebase security rules, and the test-mode trap that catches live apps.

How Firebase rules work

Firebase security rules are a small ruleset that sits in front of your Realtime Database, Firestore or Storage and evaluates every request. A rule grants read or write on a path based on conditions: is the user authenticated, does the requested document belong to them, does a field match. If no rule allows a request, it is denied. Rules are the entire access-control layer; there is nothing beneath them.

Because rules are evaluated on Firebase's servers, they hold even when a request comes straight from a script rather than your app. That is exactly why they matter: your Firebase config, including the project details a client needs, is visible in your app, so the rules are what actually protect the data.

The test-mode failure, in practice

An app left in test mode exposes everything. We have seen a Realtime Database readable from the root down, with top-level sections named users and wallets, open to anyone who found the address. We have seen Storage left open to anonymous uploads, so a stranger could place files of their choosing into the app's own bucket, which invites everything from hosting malware to running up storage costs.

None of this is visible from the app. It behaves normally. The exposure only shows when someone queries the database or storage directly with the public config, which is the first thing an attacker tries.

Writing rules that actually protect data

Start from deny. Your default should be that no read or write is allowed unless a rule grants it. Then grant precisely: a user may read and write documents under their own user id, a public collection may be read by anyone but written by no one, an admin path checks a custom claim. Match reads and writes separately, and never leave a broad allow if true in a production ruleset.

For Storage, scope uploads to authenticated users and to sensible paths and sizes, so an anonymous stranger cannot write to your bucket. For Firestore and Realtime Database, make sure nested data is covered, because a rule at one level does not automatically protect the levels below it.

How to check your rules

Open the Firebase console and read your current rules. If you see allow read, write: if true, or the Realtime Database equivalent, you are effectively in test mode and need to fix it now. Then verify from the outside: try to read and write your database and storage as an unauthenticated stranger and confirm you are refused. That external check is part of our security audit.