How do Firestore Security Rules work?
Short Answer
Security Rules are a separate, declarative configuration that Firestore evaluates server-side on every read/write request, deciding whether to allow it based on the requesting user's auth state and the data being accessed — they're your only real line of defense since client-side checks can be bypassed.
Rules are written in a rules-specific language and deployed separately from your app. A basic rule might be match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; } — only the authenticated user matching the document's ID can read/write their own document.
Because rules run entirely server-side, they're the actual security boundary — any check done only in Flutter code can be bypassed by calling the Firestore API directly, so sensitive authorization logic must live in rules. Testing rules locally via the Firestore emulator before deploying is standard practice.
Code Example
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}Common Mistakes
- ×Relying on client-side checks alone (e.g. only hiding a delete button) instead of enforcing the restriction in Security Rules.
- ×Writing overly permissive rules during development and forgetting to tighten them before shipping.
Interview Tips
- →Emphasize that rules are the real security boundary, not client-side code.