TL;DR
Never deploy with "allow read, write: if true" rules. Beyond that: write specific rules for each collection, use request.auth to verify authentication, and validate data structure inside the rules themselves. Keep the admin SDK server-side, always. This 20-item checklist covers the essentials, split by urgency: 6 critical items to fix before launch, 8 important ones within the first week, and 6 recommended for when you get to them.
Firebase gives you a production backend in minutes. That's the good part. The default security rules are effectively an open invitation, and while the console does warn you with a yellow banner, a banner is easy to scroll past when you're trying to ship. Work through this checklist and close the gaps before somebody else finds them.
Quick Checklist (5 Critical Items)
Firestore Security Rules 5
::checklist-item{label="Separate read/write permissions" description="Don't use "allow read, write" - specify each operation. How to set granular permissions"} ::
Storage Security Rules 4
Authentication 4
Cloud Functions 4
Admin SDK & Service Accounts 3
How to Use This Checklist
Go through each item before you deploy. Fix what you find as you go, rather than collecting a list to deal with later. The fastest single check lives in the Firebase Console: open Firestore or Storage and look for the yellow warning banner about insecure rules. If it's there, your database is readable by anyone who knows the project ID.
Why are open Firebase rules dangerous?
Open rules (allow read, write: if true) let anyone read and modify all your data, with no authentication at all. An attacker can copy your entire database, or wipe it. Use specific rules that check both authentication and authorization instead.
How do I check if my Firebase rules are secure?
Start in the Firebase Console: check Firestore and Storage for yellow warning banners about insecure rules. Then use the Rules Playground to walk through specific access scenarios by hand. For anything you actually care about, deploy the rules to the Emulator and write tests covering both allowed and denied access, because a rule that permits too much still passes a happy-path test.
Can I use the Admin SDK in the browser?
Never use the Admin SDK in browser code. It bypasses every rule you wrote and has full access to the project. Server-side only: Cloud Functions, your own backend, or a build script.
Scan Your Firebase Project
Our scanner checks for open rules and common Firebase security issues.