Firebase in test mode: your database is public and you won't notice

If you built on Firebase with an AI and you’re heading for launch, check one thing first: your security rules. Firebase makes it trivially easy to ship a database that anyone on the internet can read and write — and the default “test mode” does exactly that, behind a warning that’s easy to miss.

What test mode actually is

When you create a Firestore or Realtime Database, Firebase offers “test mode” to get you building fast. It sets a rule like:

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

Translated: anyone can read and write everything, until that date. No login required. It’s meant as a 30-day scaffold while you develop — but apps ship inside that window all the time, with the database wide open to the public internet. Your Firebase web config lives in the frontend by design, so anyone who finds it can talk to the database directly.

The two traps

You launch before the date. For 30 days everything works perfectly — because there are effectively no rules. Then real users arrive, and so does anyone who wants to read, overwrite or wipe your data.
The date passes. Now every request is denied and the app breaks. The fast “fix” — the one AI assistants often suggest — is allow read, write: if true;, which re-opens everything permanently. Green app, public database.

Both states look fine from the inside and leak completely.

How to check yours

In the Firebase console, open Firestore / Realtime Database → Rules. If you see if true, a future request.time date, or no request.auth check on sensitive data, it’s open.
Use the Rules Playground (simulator) to run an unauthenticated read against a user document. If it’s allowed, so is the whole internet.
Don’t forget Storage rules — the same test-mode trap applies to uploaded files.

How to lock it down

Scope every rule to the authenticated user:

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

Require request.auth != null on anything that isn’t genuinely public.
Tie documents to their owner (request.auth.uid) or membership, and validate writes.
Re-test in the simulator as an unauthenticated user and as a different signed-in user — confirm neither can reach data that isn’t theirs.

This is the Firebase version of a problem every backend has — Supabase ships with the exact same trap in row-level security. Different syntax, identical failure: the database is the real lock, and it ships unlocked.

Test-mode rules are one of the most common critical findings in vibe-coded Firebase apps — invisible until the wrong person looks. Apps with a generated backend, like those built with Bolt, hit this often because the rules are scaffolded fast and rarely revisited. A seniorgrade audit reads your actual rules and tells you what’s exposed; the free self-check is a quicker first pass.