Firebase Security Rules

Firebase tutorials show open rules to keep examples short — `match /{document=**} { allow read, write: if true; }` makes the example database work, the tutorial finish, and the developer feel productive. Plenty of apps copy that rule straight into production and never update it. Public buckets full of customer data, Firestore collections readable by any visitor with the API key (which ships in the client bundle by design), Realtime Database trees writable by anyone with curl. Firebase's security model is solid when used correctly; the failure mode is operational, not architectural. Mass scanners continuously probe Firebase projects for permissive rules, and every disclosure cycle of 'company X leaked Y million records' is a permissive ruleset that nobody noticed.

Each Firebase service — Firestore, Realtime Database, Cloud Storage — has its own rules engine, expressed in a custom DSL that runs server-side per request. Without explicit rules, the default for new projects is locked-down (since 2019). With explicitly permissive rules, the data is open to any visitor with the public API key, which ships in your client bundle by design (Firebase's security model assumes rules are the gate). The bug surfaces three ways: copy-pasted tutorial rules left in production, attempted rules that are syntactically valid but semantically broken (allow conditions that always evaluate true), and rules-as-afterthought scenarios where a developer added a new collection and forgot to add matching rules.

Customer data leak: profiles, messages, uploaded files, internal documents, payment metadata — all readable by any visitor with the API key. Write access often comes paired (most permissive rules don't distinguish read from write), letting the attacker plant content, modify others' data, fill your storage quota with junk to drive up your bill, or replace user-visible content with phishing. For consumer apps, this is the kind of incident that makes the news. For B2B SaaS, customer disclosure obligations kick in immediately.

Never ship `allow read, write: if true` to a production project. Write rules that match your data model and authorization model — for Firestore, scope every read and write to documents the requesting user owns or has permission to access. Use Firebase's local emulator (`firebase emulators:start`) to test rules during development; emulator-based tests with `@firebase/rules-unit-testing` are the right shape for CI. Audit every collection regularly for explicit rules — the absence of rules for a new collection is a deny by default, but only if you trust your team to never write a wildcard match. For Cloud Storage, scope rules per-path: `match /users/{userId}/{allPaths=**} { allow read: if request.auth.uid == userId; }`. Move sensitive data into a dedicated project where the rules baseline is stricter. Subscribe to Firebase's Security Rules anomaly detection (Spark/Blaze plan feature) so unexpected rule changes alert before they bite.