Firebase 'test mode' was meant to last 30 days. Check whether yours is still open.

If you've set up Firebase recently, you've seen the choice. When you create a Cloud Firestore database, the console asks whether to start in production mode or test mode. Test mode is the friendly option: your app can read and write data straight away, with no rules to write first.

What test mode actually does is write a rule that allows anyone, signed in or not, to read and write every document in your database, until a date 30 days in the future. It looks roughly like this:

allow read, write: if request.time < timestamp.date(2026, 12, 5);

For 30 days your database is open to the internet. Firebase warns you about this in the console and by email as the date approaches, which is good. The trouble is what happens next.

Day 31

When the date passes, the rule stops matching and every request from your app is denied. Your app breaks, usually all at once, usually at a bad moment.

The quickest way to make it work again is to remove the date:

allow read, write: if true;

This is the fix people search for, paste in, and forget. It's also sometimes what an AI tool suggests when you paste in the "permission denied" error and ask it to make the app work. The app comes back to life. And your database is now open to anyone, permanently, with no expiry email to remind you.

Why this matters more than it sounds

Firebase apps talk to the database directly from the browser or the phone. The Firebase config in your app, including the apiKey, is meant to be public. It identifies your project, and it doesn't protect anything. Security Rules are the only thing deciding who can read what.

So a rule of if true means anyone who opens your app, finds your project ID in the code, and uses the Firebase SDK can list your collections and read every document. They can also write to them.

This isn't hypothetical. In 2024, three security researchers started with a hiring platform whose Firebase setup let them in, then went looking for others. They found 900 websites exposing the data of 125 million users through misconfigured Firebase instances, including names, emails, phone numbers, billing information and, in over 20 million cases, plaintext passwords. They emailed 842 of the affected sites. According to SecurityWeek, only about a quarter fixed the issue.

Check your rules in five minutes

Open the Firebase console and look at three places, because each has its own rules:

1. Firestore Database, then Rules
2. Realtime Database, then Rules (if you use it)
3. Storage, then Rules (for uploaded files)

In each, look for any of these:

• if true
• request.time < followed by a date (test mode still active, or about to break)
• ".read": true or ".write": true in the Realtime Database
• if request.auth != null with nothing else

The last one needs explaining. It means "anyone who is signed in". It keeps out strangers who aren't logged in, but any user of your app can still read every other user's data, and signing up is free.

What good rules look like

Good rules tie data to its owner. For a collection where each user has their own documents, stored under their user ID, a rule looks like this:

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

In plain English: you can read and write documents under your own user ID, and nothing else.

Shared data needs more thought. Who can read a team's projects? Who can edit them? Who can delete them? Write those answers down in plain language first, then ask your AI tool to turn them into rules one collection at a time, and to explain each rule back to you.

Firebase's documentation has a page on fixing insecure rules, and the Rules Playground in the console lets you simulate a request as a specific user to see whether it would be allowed.

Then test it from the outside

Rules can look right and still miss a path. After updating them, sign in as one test user and try to read another user's data, both through the app and by asking your AI tool for a small script that queries the other user's documents directly. Then sign out and try again.

If you want the database-agnostic version of this, the two-account test works the same way on Firebase as on anything else. And the Tea app leak is a reminder that Storage rules fail separately from Firestore rules, so check both.