Firebase Security Rules: The Defaults That Will Burn You
Firebase is fantastic for shipping fast, which is exactly why AI assistants reach for it. But its convenience hides a sharp edge: the database often starts in a mode that lets *anyone* read and write everything, and that mode quietly stays on far longer than it should.
Test mode is an open door
When you create a Firestore or Realtime Database, Firebase offers test mode, which uses a rule like `allow read, write: if true;` — sometimes with a 30-day expiry, sometimes not. Until you change it, every document is public to read and write. Plenty of apps launch this way without realizing it.
The Firebase config is not a secret — and not a control
Like Supabase's anon key, the `firebaseConfig` object in your front-end is meant to be public. It identifies your project; it doesn't protect it. The protection is entirely in your Security Rules. Don't be reassured by 'the keys are obfuscated' — they aren't, and they don't need to be.
Writing rules that hold up
Require authentication and scope documents to their owner. A typical Firestore rule lets a user read or write a document only when `request.auth != null && request.auth.uid == resource.data.ownerId`. Validate incoming data shape too, so a client can't write fields it shouldn't.
Test rules in the Firebase console's Rules Playground and with the local emulator before you deploy.
Don't forget Storage
Cloud Storage has its own separate rules, and they're easy to overlook. An app with locked-down Firestore but open Storage can still leak every uploaded file. Lock both.