Firebase Security Rules: Stop Shipping Test Mode to Production

TL;DR: Firebase ships new projects in test mode: allow read, write: if true. That one line means anyone with your project ID can read and write your whole database. No login, no exploit — just a URL. Most vibe-coded apps launch with that rule untouched. AI builders aim for "it works", not "it is safe". The fix is owner-scoped rules: every read and write tied to request.auth.uid. Here is how to write them, and a free scan to check your live app first.

We have seen where this ends. Our Quittr breach report traces a real vibe-coded app. Its open Firebase backend left user data open to anyone who looked. Nothing about it was clever. The door was open, and someone walked in. This guide is about closing yours before launch, not after.

The rules file is the only wall

Firebase puts no firewall in front of your data. No private network. No gateway doing the job for you. The rules file is the wall. If the rule says true, there is no wall.

Here is the part most founders miss: Firebase does not ship "secure by default". It ships "working by default". For a new database, that means test mode. Anyone with your project URL can read and write everything. Fine for a weekend demo. A real risk the moment users sign up with real emails, messages, or payment records.

AI builders make this worse in a quiet way. Lovable, Bolt, Cursor, and v0 scaffold the backend, wire the app to it, and demo a working product. The rules file never comes up. You never see it until something breaks — and nothing "breaks" while it is open. It just leaks.

The loaded gun: allow read, write: if true

This is the single most common finding in vibe-coded Firebase apps. One block, copied from the quickstart, still sitting in production:

match /{document=**} {
  allow read, write: if true;
}

That rule does not ask who is logged in. It does not ask who owns the document. It says yes. Every time. To everyone. A researcher, a rival, a journalist, or anyone with a grudge can open a browser console, grab your project ID from your page source, and pull every row you have. No password. No exploit. Just a URL and some free time.

The breach pattern is almost boring in how steady it is:

1. Founder builds fast with an AI tool. Firebase handles auth and data.
2. The console goes to test mode during the build, just as the quickstart suggests.
3. The app launches. The rules ship untouched.
4. Someone finds the open endpoint and pulls the data.

That is the exact shape of the Quittr Firebase breach — the same four steps, in the same order, with real users' data on the other side.

Owner-scoped rules: the fix, line by line

An owner-scoped rule ties every read and write back to who is asking. Not "is someone logged in". But "may this exact user touch this exact thing". A working baseline:

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

Three checks every rules file needs before launch:

• An auth check on every path. Not just the ones that look sensitive. request.auth != null is the floor, not the ceiling.
• An owner check on every document. Compare request.auth.uid to the owner field, every time. Logged in is not the same as allowed.
• Field checks on writes. A user who owns a document still should not set its role, price, or isAdmin fields. Limit what can change, not just who can change it.

One more habit that pays: if you cannot explain in one sentence why a rule allows access, the rule is not ready to ship.

Three products, three rules files

Firebase is not one database. Each product has its own rules, and fixing one does not fix the rest. A very common miss: Firestore gets locked down, and the Storage bucket with user uploads stays open.

On Supabase instead? Same problem, different name.

If your AI builder wired you to Supabase, it is the same fault with a new name. Supabase calls it Row Level Security. The questions match. Is RLS on for every table? Are the policies owner-scoped, not USING (true)? CVE-2025-48757 showed the scale — 170 or more AI-built apps left readable on that stack. Our RLS policies guide covers the fix, and the free RLS checker probes a live Supabase app the same way this article probes Firebase.

Why AI builders keep shipping test mode

The numbers back the pattern. Symbiotic Security scanned 1,072 AI-built apps. 98% had at least one flaw. 16% had critical issues. CMU's SusVibes study found security flaws in 61% of AI-written code. Across 100 apps we scanned ourselves, the average Launch Readiness Score was 42/100. Open database rules were among the most common reasons.

None of this means the tools are bad. It means they stop at "runs in the demo". Rules files are the exact kind of work that never demos: unseen when wrong, silent when open, and skipped by default. That last 20% is yours to finish — or to hand to someone whose job it is.

The legal bill on top of the breach

An open rules file is not just a tech miss. Under GDPR, allow read: if true around personal data means there is no access control at all. That fails GDPR on its own, before any breach. Where your users live — not where your office is — decides if the rules apply to you. And if your app has an AI-facing feature and EU users, more rules stack on top. Article 50 of the EU AI Act applies from August 2, 2026. Its transparency rules carry fines up to €15 million or 3% of global turnover. Our GDPR guide for vibe-coded apps covers the first part, and the Compliance Wing checks both in one pass, starting with a $799 Compliance Score.

The pre-launch rules checklist

1. Open the Firebase console. Read your live rules for Firestore, Storage, and Realtime Database. All three.
2. Delete every if true. No exceptions survive contact with real users.
3. Add request.auth != null on every path, then an owner check against request.auth.uid.
4. Limit write fields. Owners edit their data, not their role.
5. Check your page source for exposed config and keys while you are there.
6. Rate-limit your auth endpoints. Test one with the free API rate limit checker.
7. Check your response headers with the security headers checker.
8. Re-scan after every fix. Fixes interact.

What checking this costs

The free scan is $0 and takes about 30 seconds. You give it your live URL. You get a Launch Readiness Score out of 100 across security, reliability, performance, and monitoring. The full Launch Readiness Audit is $499 one time. You get a branded report with every finding. You get a ranked fix plan with a time estimate per fix. And you get a benchmark against 200+ audited apps. Want it fixed for you? Done-for-you setup starts at $1,999, with a named CTO shipping each fix as a pull request you approve.

FAQ

What is the default Firebase security rule and why is it risky?

Test mode ships with allow read, write: if true. That one line lets anyone read or write your whole database with no login. It is meant for quick demos. It becomes a breach the day real users sign up.

How do I write owner-scoped Firebase security rules?

Tie every read and write to the caller. Check request.auth != null first, then check request.auth.uid matches the document owner. Logged in is not enough — the rule must ask if this user owns this data.

Do Firebase security rules cover Storage and Realtime Database too?

Each product has its own rules file. Firestore, Storage, and Realtime Database are locked down one by one. A common miss is fixing Firestore and leaving Storage buckets open. Check all three.

What happened in the Quittr breach?

Quittr was a vibe-coded app whose Firebase backend was left open, and user data was reachable with no owner checks. We published a full first-party breakdown of how the default rules led there, and what would have stopped it.

Can I check my Firebase rules without code access?

Yes. Open rules are visible from the outside — that is the whole problem. Our free scan tests your live app the way a stranger would, with no repo access and no install, in about 30 seconds.

What does a Firebase security audit cost?

The scan is $0 and returns a Launch Readiness Score out of 100. The full Launch Readiness Audit is $499 one time. It adds a branded report, a ranked fix plan, and a benchmark against 200+ audited apps.

The pattern is the one our vibe coding security guide shows for every AI stack: the code works, the defaults do not. Your app runs. Whether your database has a wall is a separate question — and it is the first thing a stranger will check.