How to check3 min readUpdated 2026-08-03

How to check your Firebase security rules are not open

Firebase starts your project in test mode: open to everyone, for 30 days. Plenty of apps ship before anyone notices.

Firebase has the same shape of problem as Supabase, in different words. Your app talks to Firestore straight from the browser, and a set of rules decides what each visitor may touch. The difference is how the project starts: open, on purpose, with a deadline.

What a dangerous ruleset looks like

Two rules that mean 'everyone'

// wide open — anyone on the internet, no sign-in
match /{document=**} {
  allow read, write: if true;
}

// open until a date, then abruptly closed
match /{document=**} {
  allow read, write: if request.time < timestamp.date(2026, 9, 1);
}

The second is what test mode writes for you. It looks deliberate, which is why it survives review — and it is what turns into 'Missing or insufficient permissions' the morning after it expires.

Check yours in two minutes

Rules Playground, then your live app

  1. 1Firebase console → Firestore Database → Rules. Read the current ruleset and look for if true or a bare timestamp condition.
  2. 2Open the Rules Playground. Set the operation to a read on a collection holding user data, and leave authentication off.
  3. 3Run it. The request should be denied. If it succeeds, your database is readable by anyone.
  4. 4Now simulate a signed-in user reading a document owned by a different user. This should also be denied.
  5. 5Repeat for create, update and delete — read rules are usually tighter than write rules, and write access is worse.

What a working rule looks like

Ownership, with the create case handled properly

match /items/{id} {
  allow read, update, delete: if request.auth != null
    && request.auth.uid == resource.data.userId;
  allow create: if request.auth != null
    && request.auth.uid == request.resource.data.userId;
}

The split matters. On a create the document does not exist yet, so resource.data is empty and a rule checking it can never pass — creates must be validated against request.resource.data. This single detail accounts for a large share of Firestore rules that look right and refuse everything.

Paste this into your AI coding tool
Audit and fix my Firestore security rules.

1. Show me the current rules and flag anything that allows unauthenticated
   access: allow read, write: if true, a bare request.time comparison left
   over from test mode, or a match on /{document=**} with weak conditions.
2. For every collection, tell me who should read and write it, and wait for
   me to confirm before changing anything.
3. Write ownership rules that check request.auth.uid against the document
   owner, using resource.data for read, update and delete, and
   request.resource.data for create.
4. Validate the shape of writes too — reject documents with unexpected
   fields or a userId that does not match the caller.
5. Check Storage rules as well; they are a separate ruleset and are usually
   the more forgotten of the two.
6. Give me Rules Playground scenarios to verify each collection: one signed
   out, one signed in as the owner, one signed in as somebody else.

Do NOT propose allow read, write: if true, even temporarily.

Common questions

What does Firebase test mode actually do?
It grants open read and write access to your database for a limited period — typically 30 days — so you can build without fighting rules. Anyone with your project ID can read and write everything while it lasts, and plenty of apps ship inside that window.
Is my Firebase apiKey a secret?
No. The Firebase config block, apiKey included, is designed to ship in your frontend — it identifies the project rather than granting access. Your security rules are what actually protect the data.
How do I test my rules without writing code?
Use the Rules Playground in the Firebase console: Firestore → Rules → Rules Playground. Set the operation to match what your app does, leave authentication off, and confirm the request is denied. Then simulate a signed-in user reading someone else's document — that should be denied too.
What is the most common mistake in Firestore rules?
Validating a create against resource.data. The document does not exist yet on a create, so that check can never pass — creates must be validated against request.resource.data. The second most common is a rule requiring request.auth on a query that runs before sign-in completes.

This is one check out of 40+

Paste your site address and we run the whole list from the outside — leaked keys, open databases, unprotected pages — then hand you one prompt that fixes what we find. Free, about 30 seconds, no signup.

Check my site — free