Firebase test mode left open? Lock your rules

The Firestore quickstart says test mode is “good for getting started” but “allows anyone to read and overwrite your data.”

The test-mode rule, word for word

This is the template the Firebase CLI writes for you. The comment is Google’s, not ours:

rules_version='2'

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      // This rule allows anyone with your database reference to view, edit,
      // and delete all data in your database. It is useful for getting
      // started, but it is configured to expire after 30 days because it
      // leaves your app open to attackers. At that time, all client
      // requests to your database will be denied.
      //
      // Make sure to write security rules for your app before that time, or
      // else all client requests to your database will be denied until you
      // update your rules.
      allow read, write: if request.time < timestamp.date(2026, 11, 15);
    }
  }
}

The mistake is what happens on day 30

When the date passes, every request from your app is denied. That’s the safe part. The danger is the quick fix: push the date out a year, or swap the condition for if true. Both keep the door open, and the second one never closes.

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this ruleset in production; it allows
// anyone to overwrite your entire database.
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

Why auth != null alone is not enough

Firebase warns about this exact rule. If a rule includes auth != null, it says to “confirm that you want any logged-in user to have access to the data”. Anyone can sign up for your app. Then they can read every record.

// Not recommended: any logged-in user can read and write everything
match /{document=**} {
  allow read, write: if request.auth != null;
}

The owner-only rule (Cloud Firestore)

Store each user’s data at users/{their uid}, then check the ID on every request. This is the sample from Firebase’s docs, exactly:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

If your documents live in a shared collection instead, save the owner’s ID in each one and check that field:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
    }
  }
}

The same lock for Realtime Database

{
  // Allow read/write access to all users under any conditions
  // Warning: **NEVER** use this ruleset in production; it allows
  // anyone to overwrite your entire database.
  "rules": {
    ".read": true,
    ".write": true
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth !== null && auth.uid === $uid",
        ".write": "auth !== null && auth.uid === $uid"
      }
    }
  }
}

1. Open the Firebase console, go to Firestore Database → Rules (or Realtime Database or Storage), and open the Rules Playground.
2. Pick get as the simulation type. For Location, enter someone else’s record, like users/some-other-user-id.
3. Set Authentication type to unauthenticated. Click Run.
4. The banner above the editor must say the request was denied. If it says allowed, your door is open.
5. Now test as a signed-in user with a specific ID. Reading their own users/<that id> should be allowed. Reading someone else’s should be denied.