A free, single-page tool that reads a firestore.rules file and flags the
security mistakes that turn up again and again in real projects.
Everything runs in the browser. There is no server, no upload, no analytics, and no network request of any kind. The whole tool is this one HTML file, so you can read it before you trust it.
Firestore will never tell you your rules are wrong. A rule that is too loose looks identical to a correct one, because the app keeps working either way. The first signal most people get is a support email or a bill.
In May 2026 a scan of roughly 380,000 apps built on AI coding platforms found about 5,000 of them leaking real data: medical records, financial documents, customer chat logs. The cause was structural rather than careless. Most of those platforms default new projects to open, and nothing in the workflow says otherwise.
This tool is the missing warning.
| Severity | Check |
|---|---|
| Critical | if true, and leftover test-mode rules with an expiry date |
| Critical | if request.auth != null used as authorisation |
| Critical | A root-level match /{document=**} that grants anything |
| Warning | A nested recursive wildcard that overrides its own parent block |
| Warning | No request.query.limit anywhere, so a query can read a whole collection |
| Warning | Roles, memberships, billing or credits that the client can write |
| Warning | An update rule that checks ownership but lets the owner field be rewritten |
| Note | allow read, write granting five operations in one line |
| Note | get() and exists() lookups, which are billed per document evaluated |
| Note | A missing or legacy rules_version |
The nested wildcard check is the one worth knowing about. A recursive wildcard
matches zero or more path segments, so match /{document=**} inside another
block also matches that block's own document. Rules are OR-based and there is
no deny, so one broad grant in there silently cancels the careful rules above
it. I shipped that exact bug in my own kit and only caught it because a test
suite failed.
It reads for known mistakes. It cannot tell whether your rules express what your application actually intends, and a clean result is not a security audit. Only tests that assert what must be denied can tell you that.
It covers Firestore only, not Storage or Realtime Database rules.
Clone and open index.html. There is no build step, no dependencies, and no
configuration.
git clone https://github.com/DeAlNu/firestore-rules-checker.git
cd firestore-rules-checkerFirestore Rules Kit is seven production rule patterns covering the shapes real apps have, each proven by an automated test suite that asserts both what must be allowed and what must be denied. 94 assertions, running on the free local emulator.
This checker finds the problem. The kit is the worked answer.
MIT. Use it, fork it, embed it, learn from it.
Firebase and Firestore are trademarks of Google LLC. This tool is independent and not affiliated with or endorsed by Google.