Firebase in test mode: the rules that leave your data wide open

Firebase is the other database AI builders reach for, and it has the same fundamental shape as Supabase: a public client config plus a rules layer that is supposed to scope access. The difference is the default. When you create a Firestore or Realtime Database, Firebase offers a "test mode" that grants open read and write to everyone for 30 days — explicitly so you are not fighting permissions while prototyping.

AI builders take that offer. The 30 days lapse, or the rules get pinned open to make the demo work, and the app ships with the equivalent of `allow read, write: if true;`. Anyone with the public config — which is in your bundle by design — can read and overwrite your data.

What "open rules" actually exposes

• Read: every document in every collection — user profiles, messages, orders — pulled straight from the client SDK or REST endpoint.
• Write: an attacker can create, edit or delete records. Open write is worse than open read because it lets someone corrupt or ransom your data, not just copy it.
• The config itself: apiKey, projectId and databaseURL are public values. They are not the vulnerability — the permissive rules are. A locked-down project is safe with its config fully visible.

How to check

Look at your rules in the Firebase console (Firestore Database → Rules, and Realtime Database → Rules). Any rule that resolves to `true` for read or write without an auth condition is open. You can also confirm empirically: an unauthenticated client read that returns documents means the rules are not protecting that collection.

The fix

• Replace blanket `if true` rules with conditions tied to request.auth — e.g. allow read, write: if request.auth != null && request.auth.uid == resource.data.ownerId;
• Default-deny: write rules so anything not explicitly allowed is rejected, rather than allowing broadly and carving out exceptions.
• Test rules in the Firebase emulator or the console's rules playground before deploying.
• Re-check from an anonymous client and confirm reads now return nothing.

VibeSafely probes Firebase and Firestore for world-readable config and permissive rules, and reports whether an anonymous request actually gets data back — the same evidence-based approach we use for Supabase RLS.