ds_rules

A security linter for Firestore and Storage rules, in VS Code. Open writes and test mode, caught as you type.

The Firestore and Storage rules mistakes that leak data, flagged while you type them rather than after someone finds them.

Security rules fail quietly. A rule that lets anyone write looks exactly like one that doesn't, the deploy succeeds, and the app works — better than before, in fact, because nothing is refused. The emulator and unit tests only catch what you thought to test. This reads the rules themselves and says, in plain words, who can do what.

What it catches

• Open writes — if true, no condition at all, or a || true hiding in one.
• A readable database — allow read: if true on match /{document=**}.
• Firebase test mode left on — and, once its date has passed, the rule that now refuses everything.
• A grant on every document — rules are OR'ed, so a root wildcard overrides every narrower rule in the file.
• Anyone can edit — update or delete for any signed-in user, which means anybody's document.
• Unvalidated writes — nothing checks request.resource, so a stranger can store any field, including someone else's user id.
• Unchecked uploads — a Storage write with no size or content-type limit.
• An unverified email claim — token.email without email_verified, before you add a second sign-in provider.
• Too many lookups, a missing rules_version = '2', and unclosed brackets or strings.

Conditions are read through the functions they call, so if isSignedIn() is judged by what isSignedIn() returns — and a role looked up on the caller's own document counts as tied to that caller, however many helpers the path goes through.

It stays quiet on purpose

A public read of published content is not a mistake, and neither is an admin writing without field checks. Those get a faint hint in the editor, not a line in the Problems panel. Google's own documented example rules produce nothing louder than a hint — that is a test, not a hope — and so did the real rules files it was tuned against.

Every check links to its explanation, can be silenced for one line with // rules-lint-ignore, or turned off in settings. It runs in untrusted workspaces too, since it only ever reads text — reviewing an unfamiliar repo's rules is exactly when you want it.

Also

Highlighting for .rules, firestore.rules and storage.rules, with wildcards, recursive =** and $( ) paths, and a misspelled method shown as invalid. Snippets for a file that starts closed, an owner-only collection, public content, an admin by verified email, and an upload with limits.

Why

It is the tool Firestore Security Rules: Deny by Default, Then Open the Narrowest Hole argues for. The full list of checks, with examples, is in the README on GitHub.

MIT licensed, source on GitHub, free like everything else here.