We scanned 173 AI-built apps. 79 shipped critical security holes.

"I built my whole SaaS in a weekend with AI" is everywhere right now. We got curious how secure those apps actually are — so we ran a security scan across 173 public apps built with AI coding tools (Lovable, Bolt, v0, Cursor). 79 of them — about 46% — had at least one critical vulnerability.

What we found

Across the 173 apps, the most common exposures, by number of findings:

The scariest one wasn't hardcoded keys

Everyone expects committed .env files and API keys — and yes, plenty of apps had them. But the most dangerous and second-most-common problem was broken access control: database rules that check whether you're logged in but not whether you're the right user. The result is that any account can read every other account's data. The app demos perfectly, so nobody notices — until someone does.

A close third: unauthenticated backend functions. Supabase edge functions deployed with verify_jwt = false, sitting in front of paid APIs like OpenAI. Anyone who finds the URL can call them and run up the owner's bill.

Why this keeps happening

AI coding tools are exceptional at generating working features. They are not good at reasoning about authorization boundaries — the invisible rules about who is allowed to see or do what. So you ship an app that works flawlessly in the demo and quietly leaks data in production. A regex-based scanner catches the hardcoded keys; it can't catch "any logged-in user can read any other user's orders" because that requires actually understanding the code.

Check your own app (free, 4 things)

• Committed secrets: search your repo for a tracked .env and any sk_ / AIza / AKIA keys. Rotate anything committed.
• Access control: log in as two different users and try to read user A's data as user B. If you can, your rules are broken.
• RLS: confirm each table's policy is auth.uid() = user_id, not just "is authenticated."
• Edge functions: any function with verify_jwt = false is callable by anyone — add auth unless it's intentionally public.

Methodology

We collected 173 publicly available apps built with AI coding tools and ran an automated security analysis over their source and (where applicable) live deployments: static analysis for committed secrets and configuration, plus checks for access-control rules, edge-function authentication, CORS, storage permissions, and security headers. "Critical" means at least one finding that exposes data or money to an unauthenticated or unauthorized party. No app, owner, or secret is named — figures are reported only in aggregate.