Firebase security rules checklist

Firebase lets the browser read and write your database directly. Security rules are the only thing standing between a user and every other user's data, so they have to be written for your app, not left at a default.

Last reviewed 2026-09-30Written by Jacob Masse, TrazTech Inc.

A Firebase app is protected by its Firestore, Realtime Database and Storage security rules and by nothing else, because the client talks to them directly. Before launch, replace any test-mode rules, tie every read and write to request.auth.uid, validate the shape of writes, apply the same thinking to Storage, and test the rules in the emulator with more than one user.

Rules

0 of 0 done · Reset

• No rule allows read or write to everyone
• Test-mode rules with an expiry date have been replaced
• User documents are readable only by their owner
• Team documents check membership stored somewhere users cannot edit
• Writes validate field names, types and sizes
• Users cannot change their own role or plan fields
• Storage rules match the Firestore ownership model

Keys and project settings

0 of 0 done · Reset

• The web API key is restricted to your domains in the cloud console
• Service account keys are nowhere in client code or the repository
• App Check is considered for abuse-prone endpoints
• Unused sign-in providers are disabled

Cloud Functions

0 of 0 done · Reset

• Callable functions check context.auth and permissions
• HTTP functions verify tokens themselves
• Functions using admin privileges validate every input

Testing rules

Write rules tests with the Firebase emulator suite: one authenticated user, a second user and an unauthenticated request against each collection. A rule that lets the second user read the first user's document is the finding. For anything holding personal information or payments, have the app security tested as well. The same logic applies to Supabase; see the Supabase checklist.

Common questions