allow read, write: if true — the Firebase rules epidemic

Firebase makes it incredibly easy to add a backend to your app. It also makes it incredibly easy to leave your entire database open to the internet. We analyzed 100 Firebase projects sourced from public GitHub repositories and found that 67% had Firestore security rules that granted unrestricted read and write access.

The default rules problem

When you create a new Firestore database, Firebase gives you two options for initial security rules: "Start in production mode" (deny all) or "Start in test mode." Test mode creates these rules:

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

These rules grant full read and write access to every document in every collection to anyone, with no authentication required. Firebase adds a 30-day expiration, but most developers either extend it or ignore the warning emails.

What we found

Of the 100 projects we analyzed:

• 67 projects had allow read, write: if true on a wildcard path
• 12 projects had rules that checked authentication but not authorization (any logged-in user could read/write any data)
• 8 projects had rules with time-based conditions that had already expired, meaning they were open by default
• Only 13 projects had properly scoped rules tied to user identity and data ownership

Why AI makes this worse

When you ask an AI code generator to "set up Firebase for my app," it typically starts with test-mode rules because they eliminate permission errors during development. The AI does not circle back to lock down the rules before deployment. Unlike a human developer who might remember to tighten security before launch, the AI treats the initial setup as complete.

We have also seen AI tools generate rules that look secure but are not. For example:

match /users/{userId} {
  allow read, write: if request.auth != null;
}

This checks that the user is authenticated, but it does not check that they are accessing their own data. Any authenticated user can read and modify any other user's document.

The correct pattern

Firestore rules should always validate that the authenticated user owns the data they are accessing:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Users can only access their own document
    match /users/{userId} {
      allow read, update, delete: if request.auth != null
        && request.auth.uid == userId;
      allow create: if request.auth != null
        && request.auth.uid == request.resource.data.userId;
    }

    // Posts are publicly readable, only writable by owner
    match /posts/{postId} {
      allow read: if true;
      allow create: if request.auth != null
        && request.resource.data.authorId == request.auth.uid;
      allow update, delete: if request.auth != null
        && resource.data.authorId == request.auth.uid;
    }

    // Deny everything else by default
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

How to check your project

You can review your current Firestore rules in the Firebase Console under Firestore Database > Rules. But reading rules alone is not enough. You should test them against realistic attack scenarios. The Firebase Emulator Suite includes a rules testing library, but setting it up requires significant effort.

A faster option: run a Sekrd scan with your Firebase project URL. We will analyze your security rules, test common bypass patterns, and generate specific fixes for every vulnerability we find. The scan takes two minutes and covers Firestore, Realtime Database, and Storage rules.