Missing Firestore Security Rules
Firestore Security Rules are the equivalent of Supabase RLS for Firebase applications. Without them, anyone who has your Firebase config (which is public by design) can read, write, and delete every document in your database.
Scan Your Firebase AppHow It Happens
Firebase projects start in test mode by default, which sets Firestore Security Rules to allow all reads and writes. This is intended for development, but developers frequently forget to change it before deploying. The Firebase console even warns about this, but the warning is easy to dismiss. AI code generators that scaffold Firebase projects often copy test-mode rules or generate overly permissive rules like allow read, write: if true. The generated app works perfectly because there are no permission errors, but the database is completely open. Even when developers write rules, Firestore's rule language has subtleties that lead to mistakes. A rule that checks request.auth != null allows any logged-in user to access any document, not just their own. Partial rules that protect reads but not writes, or protect one collection but not another, are common patterns that leave gaps attackers exploit.
Impact
With open Firestore rules, anyone can use the publicly available Firebase config to read every document in the database. Tools like firebase-explorer make this trivial: paste in the config, browse all collections, and download the entire dataset. Attackers can also write to the database: inserting fake records, modifying existing documents, or deleting entire collections. For apps that store user data, orders, or messages, this means data integrity is completely compromised. Because Firebase config is embedded in every frontend that uses it, there is zero barrier to exploitation. The attacker does not need to discover any hidden endpoint; the config is in the JavaScript bundle of the application itself.
How to Detect
Open the Firebase console, navigate to Firestore > Rules, and read the current rules. If you see allow read, write: if true or a rules_version with no meaningful conditions, your database is open. Test externally by initializing a Firebase app with your public config and attempting to read collections. If data returns without authentication, the rules are too permissive. Vibe App Scanner detects Firebase configuration in your application and tests Firestore access using the public credentials, reporting which collections are readable or writable without authentication.
How to Fix
Replace test-mode rules with restrictive rules immediately. The minimum viable rule should require authentication: allow read, write: if request.auth != null. But this only prevents anonymous access; you should add ownership checks. For user-owned data, use rules that verify document ownership: allow read, update, delete: if request.auth.uid == resource.data.userId. For new documents: allow create: if request.auth.uid == request.resource.data.userId. Structure your Firestore data to make rules simpler. Use subcollections under /users/{userId}/ so rules can check request.auth.uid == userId in the path rather than needing to inspect document fields. Deploy rules via firebase deploy --only firestore:rules and test them using the Firebase Emulator Suite. The emulator lets you test rules locally without affecting production data.
Code Examples
Firestore Security Rules
// Test mode rules (default for new projects)
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true;
}
}
}rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// User profiles: only owner can read/write
match /users/{userId} {
allow read, update, delete: if request.auth.uid == userId;
allow create: if request.auth.uid == request.resource.data.userId;
}
// User documents: owner only
match /users/{userId}/documents/{docId} {
allow read, write: if request.auth.uid == userId;
}
// Deny everything else by default
}
}Frequently Asked Questions
What is the difference between Firestore rules and Supabase RLS?
They serve the same purpose (controlling data access) but use different mechanisms. Firestore rules are written in a custom rules language and deployed separately. Supabase RLS uses PostgreSQL policies written in SQL. Both are essential for securing their respective platforms.
Does Firebase warn about open rules?
Yes. The Firebase console shows a warning banner when Firestore rules allow unrestricted access, and test-mode rules expire after 30 days. However, many developers dismiss these warnings or extend test mode indefinitely.
Can I test Firestore rules without affecting production?
Yes. Use the Firebase Emulator Suite to run Firestore locally with your rules. You can write unit tests for your rules using @firebase/rules-unit-testing to verify they allow and deny access correctly.
What about Realtime Database rules?
Firebase Realtime Database has its own rules system separate from Firestore. If your app uses Realtime Database, you need to configure its rules independently. The same principles apply: default-deny, verify ownership, and test thoroughly.
Related Security Resources
Is Your App Vulnerable?
VAS automatically scans for missing firestore rules and other security issues in Firebase apps. Get actionable results with step-by-step fixes.
Scans from $5, results in minutes.