Firestore security rules generator
Pick an access pattern, enter your collection name: get copyable Firestore security rules plus emulator test code.
How do you want to restrict access?
Tools like Firebase Studio, Lovable, and Bolt open a Firestore collection without writing the access rule that should guard it. Firebase's own docs explain the rule syntax, but they don't generate a rule for your own collection and field names. This tool generates copyable Firestore security rules for four access patterns: uid ownership, team/organization membership, public read, and admin-only via a custom claim.
Two mechanics work differently from our Supabase RLS generator, because Firestore is a different model: there's no separate "turn RLS on" line like Postgres, Firestore already denies everything by default. The team/organization pattern uses get() and exists() instead of a SQL join, both of which need the database path interpolated with $(database), so the membership document's id is the user's own uid. The admin pattern has no separate admin table: the custom claim is set only server-side with the Admin SDK's setCustomUserClaims(), and it won't show up in request.auth.token until the client signs in again, its token naturally expires, or you call getIdToken(true).
The generated rule is a template. It doesn't connect to your Firebase project or read your schema: enter your own collection and field names, then test it with the emulator before deploying, never straight to production. See which gaps repeat on layers opened by Lovable and Bolt in this guide. If you can't close the critical ones yourself, our AI project completion service picks up from there.
Frequently asked
Does this tool connect to my Firebase project?
No. It runs in your browser, doesn't connect to your project, and doesn't read your schema. It generates a rule from the collection and field names you type; test it with the Firebase emulator before you deploy it.
Why isn't there a table join in the team/organization pattern?
Firestore has no SQL join. Instead the generated rule uses get() and exists() to read your own document (keyed by $(request.auth.uid)) in the membership collection and checks its orgIds array. That's why every document in the membership collection needs to be keyed by the user's uid.
I picked the admin rule but the claim doesn't show up in request.auth.token, why?
The custom claim is set only server-side with the Admin SDK's setCustomUserClaims(). After it's set, it won't appear on the client until the user signs in again, their token naturally expires, or you call getIdToken(true).
What if I'm not sure which of the four access patterns to pick?
Each option carries a short description of who can see or change the document. If you pick wrong, the restart button resets from scratch. Nothing is saved, so no answer is ever stuck.