Firebase security rules checklist
Make sure no Firestore, Realtime Database or Storage rule allows reads or writes to everyone, and that each rule checks the signed-in user's ID against the data's owner, not just that someone is signed in. Your Firebase config and API key are public by design. Security rules are the only thing between your data and anyone who copies that config.
Remove test mode before launch
Projects created in test mode start with rules that allow anyone to read and write until a date. Before that date your data is open; after it, your app stops working. Replace them with real rules, and search your rules for allow read, write: if true.
The checklist
- No rule allows access to everyone (if true), except data you truly want public.
- Rules check ownership, for example request.auth.uid == userId, not just request.auth != null. Being signed in is not the same as owning the data.
- Write rules check the new data (request.resource.data), so users cannot set fields such as role, isAdmin or plan themselves.
- Storage rules are set separately and limit file size and type.
- Realtime Database rules are set separately from Firestore rules, if you use both.
- Admin actions run in Cloud Functions or on your server, which check the caller.
- App Check is on if you want to make abuse harder, but remember it does not replace rules: it does not decide who may see what.
How to test your rules
Use the Rules Playground in the Firebase console or the Firebase Local Emulator Suite to try reads and writes as different users. Test that user B cannot read or change user A's documents, that a signed-out visitor gets nothing private, and that a user cannot give themselves a higher role. Only test your own project.
Want it checked by a person?
Elitor tests your live app, including its Firebase rules, the way a real user would, and checks every finding by hand. There is a free check, and one-off checks start at £249.
Last updated 2026-10-21.