Firebase has a "test mode" that allows anyone to read and write your entire database. Developers enable it during development and forget to change it before deploying to production.

This isn't a rare mistake. It's constant. Millions of Firebase databases are running wide open right now because someone clicked "test mode" and never looked back.

The Default

When you create a Cloud Firestore or Realtime Database instance in the Firebase console, you get two options:

• Locked mode: Deny all access

• Test mode: Allow all access for a month

Test mode gives you these rules:

Cloud Firestore:

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

Realtime Database:

{
  "rules": {
    ".read": "now < 1701388800000",
    ".write": "now < 1701388800000"
  }
}

Notice the time condition. Test mode is supposed to lock down after 30 days. In theory, developers should update their rules before the deadline.

In practice, that doesn't happen.

What Actually Happens

Developers enable test mode to get started quickly. They build their app, test functionality, add features. The 30-day deadline approaches.

Firebase sends a warning email: "Your security rules will expire soon."

In insecure cases developers do one of three things:

1. Ignore it - the email goes to spam or gets lost

2. Extend the deadline - click the "extend for 30 days" button in the console

3. Ship insecure rules - remove the time restriction and just leave if true

Option 3 is the disaster. Once you remove the time restriction, your database is permanently wide open. No more warnings. No forced deadline. Just a production database that anyone can read and write.

The Tea App

The Tea app had 50+ million users. Their Firestore database was completely open. No authentication required. Anyone could:

• Read all user data (emails, phone numbers, locations)

• Modify user records

• Delete accounts

• Access private messages

• Extract the entire database

The breach was discovered by security researchers doing routine scans. They found the database, extracted everything, and disclosed it responsibly. Tea fixed it. But the damage was done.

Why This Keeps Happening

Firebase makes it easy to be insecure

Test mode is the default suggestion. "Get started quickly!" Locked mode requires you to write rules immediately. Developers often choose the path of least resistance.

Security rules are separate from application logic

Your app code is version controlled, code reviewed, tested. Your Firebase rules are edited in a web console or deployed separately. They don't get the same scrutiny.

No forced security checks

Firebase doesn't prevent you from deploying insecure rules. You can literally ship allow read, write: if true; to production. No warnings, no confirmation dialogs, no "are you sure?"

Developers don't understand the risk

Many developers treat Firebase like a backend-as-a-service that handles security for them. They don't realise the rules they write ARE the security. If the rules say "allow access to everyone," that's exactly what happens.

Deadlines and shipping pressure

Implementing proper security rules takes time. Learning the rules language, understanding data access patterns, testing edge cases. When the deadline is tomorrow, if true ships.

Economics

Firebase's business model is based on usage. More apps using Firebase = more revenue. Making security easy would require:

• Better defaults

• Forced security reviews before production

• Automated vulnerability scanning

• Warnings for obviously insecure patterns

All of this adds friction. Friction reduces adoption. Firebase optimises for growth, not security.

Google could force developers to implement secure rules before going to production. They don't. Because the developer who can't figure out security rules will choose a different platform.

Impact

I've found hundreds of open Firebase databases during penetration tests and security research. The pattern is consistent:

Open Firestore/RTDB instances containing:

• User credentials (emails, phone numbers, addresses)

• Payment information (stored credit cards, transaction history)

• Private messages and chat logs

• Location data and tracking information

• API keys and service credentials

• Business data (customer lists, sales records, internal documents)

Common rule patterns:

// "Test mode" shipped to production
allow read, write: if true;

// "Any authenticated user" (not much better)
allow read, write: if request.auth != null;

// "Misconfigured cascading rules"
match /users/{userId} {
  allow read: if true;
  match /private/{document} {
    allow read: if false; // This doesn't work, parent rule grants access
  }
}

What You Should Do

Never use test mode

Start with locked mode. Write rules from day one. Don't use test mode "just for development" because it’s much harder to add rules retrospectively or worse you will forget to change it.

Version control your rules

Include firestore.rules or database.rules.json in your repository. Review changes like you review code.

Test your rules

Use the Firebase Emulator to test rules locally. Write unit tests for your security rules. Don't rely on "it works in the console."

Audit production rules regularly

Set up monitoring for rule changes. Review your production rules monthly. Check for patterns like if true or missing auth checks.

Use the principle of least privilege

Default to denying access. Only grant access where specifically needed. Don't use match /{document=**} with broad permissions.

Understand cascading rules

In Realtime Database, parent rules override child rules. You can't restrict access at a child path if you granted it at a parent path.

Use a tool to audit

Run an audit before launching or during changes to ensure your infrastructure is secure with something like my tool, FireScan.

Final Thoughts

Firebase test mode is a trap. It's designed to get developers started quickly, but it creates a ticking time bomb if you forget to update your rules.

The 30-day expiration is supposed to prevent this. In practice, developers extend it or remove it entirely. Firebase doesn't prevent this because preventing it would create friction.

The security model is fundamentally broken: Firebase gives developers complete control over security through a complex rules language, then provides a "skip security" button (test mode) for convenience.

Developers click the skip button. They ship to production. They expose millions of user records. Firebase sends warning emails that get ignored.

The cycle continues. And millions of databases remain wide open because nobody forced the developer to understand security rules before deploying.

If you're using Firebase: audit your rules. Today. Don't trust that you "probably fixed it." Check your rules in the Firebase console right now.

The next person who discovers your open database might not disclose it responsibly.