Your AI built the app. These 3 holes ship with it.

Your AI builder optimised for one thing: the demo works. It did not optimise for safe. Here are the three holes I find in almost every AI-built Firebase app — what they are, how they're exploited, and the fix. The full list of twelve, with rules archetypes, a launch checklist and a self-audit, is in a packet I put together (link at the end). These three are free, right here.

1. Open rules: allow read, write: if true

The scaffold's rules grant the world full access. Test-mode rules (request.time < timestamp.date(...)) are the same hole with a 30-day fuse.

Firebase config is public by design. A scanner pastes it into a script, lists every collection, and downloads or deletes everything. Automated scanners find new open databases within days of them going live.

The fix: deploy a real rules archetype for your app type today. If you can't map your app yet, deploy a deny-all starter and migrate collection by collection. Then verify with a launch checklist — don't just eyeball it.

2. "Signed in" treated as "authorised": if request.auth != null

This one is subtle, which is why it ships so often. The rules check that a user exists, not whose data they touch. Any account can read or edit any document by ID.

The exploit: an attacker creates a free account, then iterates document IDs (or lists the collection) and reads or overwrites other users' data with their own perfectly legitimate token. Nothing about the request looks wrong — the token is real.

The fix: ownership and role checks on every rules block — isOwner(), isWorkspaceMember(), hasRole() — on every collection, not just the sensitive ones.

3. Roles stored in Firestore documents

Your users/{id} document contains role: "user", and your rules (or worse, only your UI) trust it. The user document is user-writable — that's its job.

The exploit: one console write: updateDoc(userRef, { role: "admin" }). Instant self-promotion, and every admin-gated rule in the app falls with it.

The fix: roles live in custom claims, set only via the Admin SDK. Remove role and plan fields from every client write allowlist, so no client can ever write its own privileges.

The pattern

All three are the same decision: the client was trusted with something only a server may decide — who you are, what you may touch, what a thing costs, whether money moved. If you audit your own app, ask the one question that finds all twelve holes: "What is my client currently trusted to declare — and why do I believe it?"

The full packet

I packaged the full twelve holes, four production rules archetypes (SaaS roles, content app, e-commerce, deny-all migration), a launch checklist, a self-audit, and guides for App Check, custom claims and backups into LaunchGuard — a Firebase Launch & Security Kit for AI-built apps. $79 for a single project, $199 for up to five.

Store page: https://shloimyzf.github.io/pls/counterkit/launchguard/ — order by email, pay in Bitcoin, download the same day.