Firebase Rules Open to Everyone

Why it matters

Firebase clients talk to the database straight from the browser, so the rules file is the only access control there is. `if true` means any person, signed in or not, can read every document or overwrite it. The project ID needed to do that is in your JavaScript bundle. This is the most common way Firebase apps leak all their users' data.

What it looks like

This is the shape of code that triggers the rule. AI tools produce it because it works, and nothing tells them it is unsafe.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

The smallest fix

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

The better fix

If you have a few more minutes, this is the approach that holds up as the app grows.

// Write one match block per collection, and for shared data check a
// field on the document rather than only that someone is signed in:
match /orders/{orderId} {
  allow read: if request.auth != null && resource.data.ownerId == request.auth.uid;
  allow create: if request.auth != null && request.resource.data.ownerId == request.auth.uid;
}

Let your AI tool fix it

When the scanner finds this in your project, it fills in the file and line for you. This is the prompt it gives you to paste into Claude Code, Cursor or whatever you use.

How to check the fix worked

1. In the Firebase console Rules Playground, simulate an unauthenticated
   read of a document. It must be denied.
2. Simulate a read as user A of a document owned by user B. Denied.
3. Simulate user A reading their own document. Allowed.

Further reading

• https://firebase.google.com/docs/rules/insecure-rules