What should I do when Firebase test mode expires?

If your app suddenly can’t load or save anything, the logs say Missing or insufficient permissions, and you started your Firestore database in test mode about a month ago, your data is still there. The rule that let anyone read and write has reached its end date, so every request from your app is denied until you publish new rules.

Why it happens

When you start in test mode, your rules look like this, with a date 30 days after the day you created the database:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.time < timestamp.date(2026, 11, 30);
    }
  }
}

The comment that comes with it explains that it’s set to expire because it leaves your app open to attackers. Once the date passes, the condition is false for every request, so everything is denied. Don’t just move the date forward to get your app back, because that reopens the whole database, and anyone who guesses your project ID can read, change, or delete your data.

How to fix it

1. Decide who can do what with each collection. For the rules below, we’re assuming a private document for each user, plus posts that everyone can read and only the author can edit.

2. Replace the test rule with rules built on request.auth, which is the signed-in user:

   rules_version = '2';
   service cloud.firestore {
     match /databases/{database}/documents {
       match /users/{userId} {
         allow read, write: if request.auth != null && request.auth.uid == userId;
       }
       match /posts/{postId} {
         allow read: if true;
         allow create: if request.auth.uid == request.resource.data.author_uid;
         allow update: if request.auth.uid == resource.data.author_uid
           && request.auth.uid == request.resource.data.author_uid;
         allow delete: if request.auth.uid == resource.data.author_uid;
       }
     }
   }

   resource.data is the document as it’s saved now, and request.resource.data is the document as it would be after the write. Checking both on update stops someone from handing a post to a different author.

3. Try them before you publish. In the Firebase console, open Databases & Storage, then Firestore, then the Rules tab, and click Rules Playground to simulate reads and writes as a signed-in or signed-out user.

4. Publish. In the console, click Publish. If your rules live in your project, deploy them with the Firebase CLI:

   firebase deploy --only firestore:rules

5. Give it a few minutes. New rules can take up to a minute to affect new queries, and up to 10 minutes to reach listeners that are already open.

How you know it’s fixed

Signed in, your app loads and saves its own data again. In the Rules Playground, a signed-out read of someone’s users document is denied, and the same read as that user is allowed.

If it still says “insufficient permissions”

Rules aren’t filters. If a query could return even one document the user isn’t allowed to read, the whole query fails, so add a condition that matches your rule, like where("author_uid", "==", user.uid). Also check that the user is signed in when the request runs, because currentUser can be null while Firebase Auth is still starting, and an auth state observer avoids that.

If you also use Cloud Storage or Realtime Database, each has its own rules in its own section of the console. And be wary of rules that only check request.auth != null, since that lets every signed-in user read everyone’s data.