· ReadyStack
Worked example
Real numbers from this tool, line by line.
10 findings on 6 lines of a 22-line firestore.rules file: that is what comes back when a solo Firebase developer runs an audit over the ruleset a coding assistant wrote for them last month. Three of the ten are errors. One of them means the app is already broken for real users, and nobody has noticed yet.
Firebase security rules are the only thing between a public endpoint and your users' documents. There is no server in front of Firestore to check a session; the rules file is the check. It is also the file most likely to be generated, skimmed and forgotten, because it is short, it looks declarative, and a wrong line fails open instead of failing loudly. firebase deploy --only firestore:rules will publish a ruleset that lets anyone with your project ID page your entire users collection, and print success.
The line that expires
Firebase's test-mode template is written to expire 30 days after you create the database:
match /{document=**} { allow read, write: if request.time < timestamp.date(2026, 8, 20); }
Before that date, every document in the project is world readable and world writable. After it, the same line denies every client read and write, and the failure arrives as a broken app rather than as a warning in a terminal. Both states are findings, and not the same one, so the audit takes a date. Run the sample ruleset as of 2026-09-14 and it reports that client access has been denied since 2026-08-20. Run the same text as of 2026-08-01 and it reports the opposite: the database is open to the internet for another 19 days.
The four lines nobody re-reads
The rest of the sample is ordinary generated Firebase code, and each line is wrong in a way that reads as right:
allow read: if request.auth != null;on/users/{userId}. Any signed-in account reads every user document. Anonymous auth counts as signed in, and so does self-serve sign-up.allow write: if request.auth != null;on the same path. The path captures a user id and the condition never compares it torequest.auth.uid, so one customer writes another customer's document. The condition also checks who is writing but never what is written, so a client can set its ownrolefield.allow read, write: if true;on a config document. Open to anyone who knows the project ID.allow read, write: if request.auth.uid == 'Yk3QpZ7mTnUaB2cE';. A literal uid is a permanent backdoor that survives every role change, and rules files ship inside the repository.
Add the missing rules_version = '2'; on line 1, which quietly changes how the recursive wildcard matches, and that is 10 findings across 6 lines.
Why the emulator does not catch this
The Firebase emulator and the Rules Playground answer the cases you write. They will confirm that a request you imagined passes or fails. They will never volunteer that read also grants list, that a date passed last month, or that a path variable is never compared to the caller. An audit that reads the file itself surfaces the cases you did not think to write, which are precisely the ones a generated ruleset contains.
What it costs either way
Freelance Firebase developers are quoted at $120 an hour, and a manual pass over one project's rules takes roughly an hour, repeated every time the rules change. Firestore Rules Guard runs 13 rules over the file in under a second. The corrected version of the same ruleset returns 0 findings.
The audit of the file you have open is free, in the editor and in the browser, with no key and no account: https://getreadystack.com/tools/firestore-rules-guard
15 seconds — what it actually does
Questions people ask
What does Firestore Rules Guard actually do?
It reads the firestore.rules or storage.rules file open in your editor and reports every line that grants more access than it appears to grant. Thirteen rules cover public grants, test-mode dates, recursive wildcards, missing owner checks, unvalidated writes and uncapped Storage uploads. Each finding carries a line number and the runtime effect of that line.
Who is this for?
Solo developers and small product teams shipping a Firebase app, especially anyone whose firestore.rules file was drafted by a coding assistant and never reviewed line by line. It is also for the developer answering a customer security questionnaire who needs to show that the ruleset was checked and dated before deploy.
Why is the Firebase emulator not enough?
The emulator and the Rules Playground answer the cases you write. They tell you whether a request you imagined passes; they never tell you that read also grants list, that a test-mode date expired last month, or that a userId path segment is never compared to request.auth.uid. This audit reads the file itself, so unwritten cases still surface.
What is free and what needs a licence key?
Free is complete for one file: open a .rules file, run the audit, get every finding with its line number, locally, with no key or account. The licence key changes scope and ownership only, never depth: it audits every .rules file in the workspace at once and writes a dated Markdown evidence report you keep.
What would this cost done by hand?
Freelance Firebase developers are quoted at $120 an hour, and a manual pass over one project's rules takes roughly an hour, repeated every time the rules change. The extension is $29 once, with one licence key per person or team seat and and it reruns in under a second.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Firestore Security Rules Lint - open rules and missing auth checks the file you open against 13 rules from a rule set dated 2026-09-20, and points at the exact line. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.