← All guides

Common security problems in AI-generated apps

After enough AI-built applications, the findings stop being surprising. The same six patterns account for most of what we see — and they share one cause.

8 min read · Updated September 2026 · Vibestruct

There is a structural reason AI-generated apps fail in consistent ways, and it is worth understanding before the list, because it tells you where else to look.

Generation is guided by what the prompt asked for, and prompts describe what the product does. “Users can save their notes” is a feature. “Users cannot read each other’s notes” is a security control, and it is invisible in every screenshot of the finished product. Models produce the first reliably. The second only appears if someone names it.

So the pattern is not random bugs. It is a systematic absence of the things you cannot see.

1. Secrets in the front-end bundle

A key gets pasted into the client code so the feature works, and it ships to every visitor. Service-role database keys are the worst case: they are designed to bypass every access rule you later write, so their presence makes the rest of your security model decorative.

What it costs: full read and write access to your data, with no login required, for anyone who opens developer tools.

What fixing it involves: rotating the key first — on the assumption it is already compromised — then moving the calls that needed it to a server-side route, and keeping only publishable keys in the browser.

2. Authorization that lives in the browser

The most common single finding. A flag in local storage says the user is signed in, or an admin; the interface reads it and decides what to show. Nothing on the server re-checks.

This usually looks perfect in testing, because testers do not edit their own local storage.

What it costs: any user who knows how to open a browser console can become any role your app has.

What fixing it involves: moving sign-in to a real identity provider, verifying the session on the server for every request that touches data, and treating the interface as a convenience rather than a gate.

3. Database tables open to the world

Hosted databases like Supabase and Firebase are reachable directly from the browser by design — that is the point of them. Access rules are what make that safe. Getting a prototype working usually involves turning those rules off or writing one that permits everything, and that state tends to survive into launch.

What it costs: every record in the table, readable and often writable, by anyone who finds the endpoint. This is the single most common source of the “small startup leaks all its user data” story.

What fixing it involves: enabling row-level security on every table and writing policies that scope rows to the signed-in user, then re-testing every feature, because some of them were relying on the absence of rules.

4. Payments confirmed by the browser

Checkout works on the first attempt, which is why it rarely gets a second look. The gap is what happens after: access is granted because the browser arrived at a success page, rather than because the payment provider confirmed the payment to your server.

What it costs: anyone who visits your success URL directly gets whatever paying gets. Refunds, chargebacks and failed renewals also have no path to remove access.

What fixing it involves: a webhook endpoint that verifies the provider’s signature, records entitlement server-side, and handles the unhappy events — failure, cancellation, dispute — not just the happy one.

5. Input that goes straight through

Generated code tends to trust what it is given. User input reaches the database, the file system, an email template or another API without being checked for shape, size or content.

What it costs: ranges from a broken page to stored cross-site scripting that runs in your other users’ browsers, depending on where the input lands.

What fixing it involves: validating on the server against an explicit schema, escaping on output, and setting limits on size and rate.

6. One environment, doing everything

Development, testing and live are the same app, the same database and the same keys. Every change is made against real customer data, and there is nowhere safe to try anything.

What it costs: not a breach, usually — an outage, or a bad migration you cannot undo. It also makes every other fix on this list riskier to apply, which is why it is worth doing early.

What fixing it involves: a second environment with its own database and keys, and a deployment path where changes reach it first.

Why this is not an argument against building with AI

Building an MVP in a weekend is genuinely new and genuinely valuable. The mistake is not using the tools — it is assuming that because the product works, the parts you cannot see were also handled.

They are a separate body of work with a separate skill set, and they are much cheaper to add to a working product than to discover after a launch.

Common questions