Ctrl+Z Therapy
Cases10-minute checklistHow we testSend it in

One rule let everyone read and write your data

In this controlled demo, the Firestore security rules say allow read, write: if true. True means everyone, including people who never logged in.

Technical name: Firebase · Firestore security rulesControlled demo · fake data

Demo built and tested 17 Sept 2026 · Published 23 Sept 2026 · Last reviewed 23 Sept 2026 · By Ctrl+Z Therapy (how we test)

Can anyone read and write my Firebase database?

Yes, if your Firestore security rules say allow read, write: if true. True means every request is allowed, including requests from people who never logged in. The fix is a rule that checks the signed-in user owns the document they are asking for.

How to tell if your app has this

No code needed.

  1. In the Firebase console, open Firestore Database > Rules. Look for if true, or a test-mode rule based on a date (request.time < ...).
  2. Look for match /{document=**}. A broad match with a loose condition applies to every collection.
  3. Use the Rules Playground in the console: run a read as an unauthenticated user. It should be denied.

Before and after

Before
match /{document=**} { allow read, write: if true; }
GET /users · no login
200 OK

No login, no token, and the demo users came back.

After
match /users/{userId} { allow read, write: if request.auth.uid == userId; }
GET /users · no login
PERMISSION_DENIED

Same request, still no login: permission denied.

Why AI-built apps end up with this

New Firestore databases can start in test mode, with rules that allow everything for a limited time. When those rules expire and the app stops working, the quickest way to make it work again is to open them fully. AI tools that are asked to "fix the permission error" can suggest exactly that.

Fix it yourself

How do I fix it? Paste this into your AI tool

My Firestore security rules contain `allow read, write: if true`. Replace it so a user can only read and write their own document in /users/{userId} (request.auth != null && request.auth.uid == userId), and remove any broad match that still grants access. Then show me how to test it in the Rules Playground: signed out is denied, a user on their own document is allowed, another user on that document is denied.
Works with Lovable, Bolt, Cursor, Replit and similar tools. Then run the check-up below on your own app.

What the demo shows

Same request before and after the fix
Same requestBeforeAfter
Request with no login200 OK, demo usersPERMISSION_DENIED

Shown in the demo video. Test these on your own app before you rely on them.

Common mistakes when fixing this

  • Requiring a login is not enough. A logged-in stranger is still a stranger; the rule has to check ownership.

Questions people ask

Isn't requiring a login enough?

No. request.auth != null only proves someone is signed in. Any signed-in stranger could still read everyone's data. The rule also has to check ownership, for example request.auth.uid == userId.

Do my rules apply to my own server code?

No. The Firebase Admin SDK on a server ignores security rules. Rules protect requests from your app's users, so test them with a normal signed-in client or the Rules Playground, not with admin access.

Do subcollections inherit my rules?

No. A rule for /users/{userId} does not cover /users/{userId}/orders. Each subcollection needs its own match with its own ownership check.

For developers: the cause and the fix in code
− allow read, write: if true;
+ match /users/{userId} {
+   allow read, write: if request.auth != null
+     && request.auth.uid == userId;
+ }

Simplified. Your stack will look different; the principle is the same.

Learn more