Firebase Security Rule Leak Tester
Are your Firebase paths accidentally public?
Answer 10 questions about your security rule patterns. The auditor scores your configuration against the most common Firestore and RTDB misconfigurations — and gives you a prioritised fix list. Runs entirely in your browser, never connects to Firebase.
Get on Google Play
Security rule audit checklist
Check every pattern that applies to your current security rules
Get it on
Google Play
Why Firebase security rules fail in production
Firebase security rules are your only server-side access control layer. There is no backend to add middleware to — the rules are the backend. A single misconfigured rule can expose your entire database to anonymous writes.
The development shortcut that never got removed
The most common leak: a developer sets allow read, write: if true; during local testing to remove friction, ships to production, and never revisits the rules. The Firebase default rules in many older SDKs used this pattern. Google's "Have I Been Pwned" equivalent for Firebase found millions of publicly accessible databases in 2020–2024.
Auth-gated but not ownership-gated
Requiring request.auth != null blocks anonymous access but lets any authenticated user read any document. If user A knows user B's UID (often predictable from public profile paths), they can construct the exact Firestore path and read B's private data. Ownership must always be validated.
Wildcard path matches parent collection
Firestore rule matching is hierarchical but not transitive. A rule on /users/{userId} does not automatically protect /users/{userId}/private/{doc}. Subcollections must be explicitly secured. Many developers assume parent rules cascade — they don't in Firestore.
Rules that use get() without caching
Rules that call get() to look up roles add latency and count as billable reads. If the role document doesn't exist (e.g., a new user), get() returns null and an unchecked null can evaluate to allow. Always use getAfter() in write rules and check for null explicitly before accessing nested fields.
Top 10 Firebase security misconfigurations (2026)
| Misconfiguration | Risk | Scope |
|---|---|---|
allow read, write: if true on any path |
Critical | Both |
| No auth check on publicly readable collections | Critical | Both |
| Auth required but no ownership check on user data | High | Firestore |
| Subcollections not independently secured | High | Firestore |
| Write rules allow any field to be modified | High | Both |
| Admin collection not explicitly locked down | Medium | Both |
| Role checks using get() without null guard | Medium | Firestore |
| No rate limiting on write operations | Medium | Both |
| Custom claims trusted without expiry check | Low | Both |
| Rules never reviewed after feature additions | Low | Both |
Based on Firebase security research, public vulnerability disclosures, and Google Firebase documentation as of 2026. Risk levels assume a production app with real user data.
How to use this security auditor
Pull up your current Firebase security rules
Open the Firebase console → Firestore → Rules (or Realtime Database → Rules). Keep your rules visible in a separate tab while you answer the checklist questions. Do not paste your rules into this tool — answer the pattern questions instead.
Check every pattern that exists in your rules
Work through each question methodically. Look at every collection and subcollection in your rules. A pattern that only exists on one collection still counts as a checked item — risk is assessed per presence, not per prevalence.
Prioritise critical and high findings first
Critical findings mean unauthenticated access is possible right now. Fix these before anything else. High findings mean authenticated users can access data that isn't theirs. Medium and low findings are hardening improvements that reduce attack surface over time.
Test fixes in the Firebase console Rules Simulator
After updating your rules, use the Firebase console's Rules Playground to simulate unauthenticated access, authenticated access, and admin access against each critical collection. The Firepulse app lets you monitor your Firebase projects' error rates and usage changes after the security rule update deploys.
FAQ
What is the most dangerous Firebase security misconfiguration?
allow read, write: if true; on any collection. This grants full public read and write access to anyone with your Firebase project ID — no authentication required. Google has published multiple advisories about this pattern being found in millions of Firebase projects. It should never appear in production security rules.
Can unauthenticated users access my Firebase data?
Yes, if your rules don't require authentication. Any rule that evaluates to true without checking request.auth != null will allow unauthenticated access. This is a common mistake when developers set permissive rules during development and forget to lock them down before deploying.
Does this tool actually test my Firebase project?
No. This is an educational audit checklist that runs entirely in your browser. It asks about your rule patterns and scores your configuration against known vulnerability categories. It does not connect to Firebase, make any network requests, or have access to your project credentials. For live rule testing, use the Firebase console's built-in Rules Playground.
Is allow read: if request.auth != null enough?
Usually not. Requiring authentication prevents anonymous access, but any authenticated user can read any document if ownership is not enforced. You typically also need request.auth.uid == resource.data.userId to ensure users can only read their own data. Otherwise, user A can read user B's documents by constructing the correct path.
Is my audit data saved anywhere?
Your checklist answers are saved to localStorage under fp-firebasesecurityruletester-v1 so they persist across page refreshes. They are never sent to any server. Clear your browser's localStorage or click "Reset" to wipe the saved state.
Related Firepulse tools
Monitor Firebase error rates live — on your phone
Firepulse shows Crashlytics, Analytics, and function errors across all your Firebase projects. Catch the anomaly before the incident report arrives.