Paste a firestore.rules file. See each risky rule with a severity, the rule text, the risk in plain words and a fix, plus who can read and write each path.
To check Firestore security rules, paste your firestore.rules file: the tool reads its match blocks, wildcards, allow statements and functions, then lists every risky rule with a severity, the rule text, the risk in plain words and a fix. It follows the grammar in the Firebase Security Rules reference. Nested match paths are joined, so match /cities/{city} with a nested match /landmarks/{landmark} is read as /cities/{city}/landmarks/{landmark}. {id} matches one path segment and {document=**} matches a whole subtree. Allow statements may name read, write, get, list, create, update or delete, and an allow with no condition always allows. Functions are followed when a rule calls them, including their arguments and let variables. The tool reads the rules but never runs them. Each condition is sorted into a class from its shape: public (always true or missing), signed-in (request.auth != null), owner (request.auth.uid compared with a path variable or a document field) or custom (everything else). A class is an upper bound on who can pass, not a promise about who does. Syntax errors are shown with line numbers and never repeat your text.
A document can match more than one match block. Firebase grants access if any matching allow statement passes, a logical OR, so a strict rule cannot take back what a looser one grants. The documentation's own example has match /cities/{city} with allow read, write: if false, and match /cities/{document=**} with allow read, write: if true. Every read and write in cities is allowed. Checked with rules_version 2, that file gives one High finding (anyone can write) and one Medium finding (the two matches overlap), which is a score of 65. The access table shows the effect on the stricter path, for example Denied; Public via /cities/{document=**}. To restrict something, remove the broader grant. Adding an if false next to it does nothing. A recursive wildcard at the top, match /{document=**}, covers every collection, including ones you add later, and leaves no room for narrower rules.
A rule such as allow read, write: if request.time < timestamp.date(2026, 11, 14) is open to everyone until that date. The checker compares the date with the day you set (today's UTC date unless you change it, because Firebase timestamps are UTC) and reports a High finding while the date is ahead, or a Medium finding once it has passed, because the rule then denies every request. Checked on 2026-10-15, one match /{document=**} with that rule has one High finding: a score of 75, graded C. The other checks are: writes with no request.auth test; signed-in users who can write any document; update rules that compare resource.data.uid with request.auth.uid but never check request.resource.data.uid, so the owner can hand the document over or set a role or admin field; one write rule for create, update and delete; list rules without a request.query.limit; functions that are not defined or call themselves; recursive wildcards used in collection group rules without rules_version 2; and get() or exists() calls, which are billed reads (limits: 10 per single-document request or query, 20 for batches and transactions).
The score starts at 100 and loses 25 for each High finding, 10 for each Medium and 3 for each Low. Info items cost nothing. A is 90 or more, B 75, C 60, D 40 and F below 40. Any High finding caps the grade at C. The grade is a rough guide to these checks and is not a security audit. The tool does not execute conditions, so it cannot tell that resource.data.visibility == 'public' is true for a given document. It also cannot see your data, your app code or the queries your app sends, and it does not read Cloud Storage rules (service firebase.storage), which are refused with a message. Admin and server SDKs bypass these rules altogether, so those need IAM instead. Rules over 256 KB (measured in UTF-8 bytes) are refused because Firestore does not accept them. Test real requests in the Firebase rules simulator or the emulator before you publish.
Open your firestore.rules file or the Rules tab in the Firebase console, copy everything, and paste it here. Each finding shows the rule, the risk and a fix, for example splitting allow write into create, update and delete or adding request.auth != null. The access table shows who can get, list, create, update and delete every matched path.
No. It lets anyone, signed in or not, read, overwrite and delete every document the match covers, and your app's Firebase config is public. The Firebase docs say never to use it in production. Use request.auth != null as a floor and compare request.auth.uid with the owner for per-user data.
The request is allowed if any matching allow statement passes. A match /cities/{city} with if false and a match /cities/{document=**} with if true still allows every read and write in cities. The checker reports the overlap as Medium and shows the looser class next to the stricter path.
A rule with request.time < timestamp.date(2026, 11, 14) is true only before that day. From 2026-11-14 it denies every request, and the app shows permission-denied errors. The checker marks it Medium once the date has passed. Replace it with sign-in and ownership conditions rather than moving the date.
Up to 10 per single-document request or query, and 20 for multi-document reads, transactions and batched writes, with the 10 limit also applying to each operation. Going over means permission denied. Each call is a billed document read even when the request is rejected, and cached calls do not count.
No. The text is processed in your browser and not uploaded. Nothing you paste is saved either, and the findings quote at most 120 characters of a rule.