Top 5 Security Mistakes AI-Built Apps Make

Every AI builder ships fast. That's the whole appeal. But speed means the same handful of security mistakes show up over and over — because the AI generates a working app, not necessarily a safe one, and nobody's specifically checking for the difference. Here are the five we see most.

1. Live secret keys sitting in the JS bundle

The most common — and most serious — issue by far. A sk_live_ Stripe key, a Supabase service_role key, or an AWS AKIA… credential gets pasted into a .env file that then gets bundled straight into the client-side JavaScript your browser downloads. Anyone who opens dev tools and searches the page source can copy it and use it as you.

Why it happens: the AI doesn't always know the difference between a key that's safe to expose to the browser (like a Stripe publishable key, pk_) and one that absolutely isn't (the secret key, sk_). Both get treated as "config" unless someone tells it otherwise.

The fix: move secret keys server-side, rotate any key that's already been exposed, and only ever ship publishable/client keys to the browser.

2. Row-Level Security left off on Supabase

Supabase (and similar backends) default to a database anyone can query directly from the client. Row-Level Security (RLS) is the setting that restricts each user to their own rows — and it's easy to skip because the app works perfectly without it during testing. It only becomes a problem once someone else finds the endpoint.

Why it happens: RLS is opt-in, not opt-on, and enabling it requires writing policies most non-technical builders have never heard of.

The fix: enable RLS on every table and write policies that scope reads/writes to the authenticated user's own rows — most AI builders can do this in one prompt once you know to ask for it.

3. Missing security headers

Headers like Content-Security-Policy, X-Frame-Options, and HSTS are the browser-level guardrails that stop clickjacking, content injection, and downgrade attacks. They cost nothing to add and are almost always simply absent from AI-generated deploys, because they're invisible — the app looks and works identically with or without them.

Why it happens: nothing in the build-and-preview loop ever surfaces a missing header. There's no error, no broken button — just a silently weaker app.

The fix: a short server config change (most hosting platforms support this with a few lines), and it's done once, forever.

4. Wide-open CORS

Cross-Origin Resource Sharing (CORS) controls which websites are allowed to call your backend from the browser. A permissive Access-Control-Allow-Origin: * is a common AI-generated default because it "just works" in every testing scenario — every origin can reach the API without a CORS error getting in the way.

Why it happens: restrictive CORS causes visible errors during development; permissive CORS causes invisible risk in production. Guess which one gets shipped.

The fix: lock the allowed origin list down to your actual production domain(s).

5. Exposed environment and config files

Every so often, a /.env or /.git/config is reachable directly at a URL — a leftover from a deploy step or a default that was never locked down. These files can contain every secret the app uses, all in one place.

Why it happens: these files are meant to stay server-side by convention, not by an actual access rule — if nothing blocks the request, the file is served like any other static asset.

The fix: confirm these paths return a 404, not a 200, and add hosting-level rules if they don't.

The pattern

None of these five require an attacker with special skills — they're the kind of thing a search engine or a curious visitor stumbles into by accident. Roughly a third of publicly scanned AI-built apps have at least one issue this serious. The common thread isn't carelessness — it's that nobody's job, human or AI, is to specifically check for this after the "build" step finishes.

See where you stand: run a free scan and get a plain-English report on all five, with a copy-paste fix for anything we find.