Why do AI-built apps ship with the same security holes?
AI coding tools optimize for the demo, so the security steps get skipped the same way every time. The three holes that repeat, the evidence, and the fix loop.
Why does the same hole appear in every AI-built app?
Regarding why the holes repeat, the answer is the demo. AI coding tools optimize for one thing: a working app on screen in minutes. Security steps - row level security, secret handling, route guards - are not part of that demo, so they get skipped the same way every time, on every stack, for every builder. Lovable is built to get a working app in front of you fast; the steps that make an app safe for strangers are not part of the demo flow.
Regarding why the skipping is not random, look at what the demo needs. Because the demo needs data on screen, the AI connects the database directly. Because the demo user should see everything, the admin route ships without a guard. Because the table must accept writes in the demo, RLS gets turned off - and turned back on never. Each shortcut is a decision the tool made for you, and each one lands in the shipped app.
The failures are not creative: they are the demo's architecture, shipped. (Source: DevMeth catalog, C1-C48)
Which holes repeat most often?
Regarding the catalog itself, DevMeth exists because the failures are few enough to enumerate: 48 known patterns across seven themes, from secrets to auth to dependencies. Three patterns account for most of what ships broken in AI-built apps.
| Pattern | Where it hides | Check |
|---|---|---|
| RLS disabled | Supabase user-facing tables | C6 |
| Key in the client bundle | NEXT_PUBLIC_* misuse | C1 |
| Open admin route | Unguarded dashboard routes | C7 |
Table: Three of the ten free Critical checks and their signals.
Regarding the severity of these three, none is an edge case. C6 - a user-facing table with row level security disabled - means every authenticated user reads every row. C1 - an API key in the client bundle - means every visitor downloads your secret. C7 - an unguarded admin route - puts destructive endpoints one guessed URL away. The OWASP Top 10 has ranked broken access control at the top for years; AI tooling made it the default starting position. (Source: OWASP Top 10)
Three checks - C6, C1, C7 - cover the holes that ship most often, and all three run free. (Source: DevMeth catalog)
What did people actually find in shipped Lovable apps?
Regarding real-world evidence, this is not hypothetical. A study of 170+ Lovable apps found recurring Supabase misconfigurations, with open tables and exposed keys leading the list. A developer who queried 50 Lovable-built databases directly reported the same shape of result: readable data behind no policies. The observation keeps repeating in builder forums, including a r/vibecoding thread dedicated to exactly this problem.
Regarding the pattern behind the anecdotes, the studies disagree on nothing. Different samples, different methods, same failures: open tables, exposed keys, unguarded routes. When independent checks of independent apps converge on the same short list, the failures are not bad luck - they are the default path.
Two independent studies and a community thread converge on the same short list of holes. (Source: hubql study; dev.to 50-app check)
How do you close the holes before strangers find them?
Regarding the fix loop, the flow is scan, fix, re-scan. Run the free scan - 10 Critical checks, no signup, results in about two minutes. Every finding arrives masked (your secret never prints in the report) with a paste-ready fix prompt for Cursor or Claude Code. Applying the RLS fix is one line of SQL per table; Supabase's own documentation covers the mechanics. Then re-scan: the same input produces the same findings, so the re-scan measures exactly one thing - whether C6 still fires on that table.
Regarding what green means, precision is the product. Verified-green means all known patterns were checked and clear. It does not mean "secure" - DevMeth is a pre-flight check, not a pentest, and it does not replace one. What it replaces is hope: a finite, cheap, repeatable check instead of an assumption. (Source: DevMeth scan loop)
A re-scan after the fix is the only evidence that the fix shipped. (Source: DevMeth re-scan loop)
Are AI-built apps safe to ship?
Regarding the ship decision, the honest answer has two parts. Unchecked, an AI-built app carries the demo's shortcuts straight to production - the studies above show that is the norm, not the exception. But the same repeatability that creates the risk makes it checkable: 48 known patterns, 10 Critical checks free, fix prompts your AI tool applies, and a re-scan that verifies the fix. The tools shipped the holes; the same workflow closes them.
Predictable failures are the fixable kind - check the catalog before strangers do. (Source: DevMeth catalog)
About the Author: Nick Thorp is the founder of DevMeth, the pre-flight security check for AI-built apps - 48 known failure patterns, plain-English findings, paste-ready fix prompts. He also built Proven Duty, file-review tooling for UK advice firms. Connect on LinkedIn.
Frequently asked questions
Why does the same hole appear in every AI-built app?
AI coding tools optimize for a working demo on screen in minutes. Security steps - RLS, secret handling, route guards - are not part of the demo, so Lovable, Cursor, and Claude Code skip them identically every time.
Which holes repeat most often?
Three account for most of it: Supabase tables with row level security disabled (C6), API keys shipped in the client bundle (C1), and admin routes without auth guards (C7). All three are Critical checks in the free tier.
What did people actually find in shipped Lovable apps?
Two independent checks converged: a study of 170+ Lovable apps found recurring Supabase misconfigurations, and a developer who queried 50 Lovable-built databases directly found readable data. Same failures, different samples.
How do you close the holes before strangers find them?
Scan, fix, re-scan. Run the free scan - 10 Critical checks, no signup, about two minutes. Paste the fix prompt into your AI tool, then re-scan: determinism means the re-scan measures exactly whether the fix shipped.
Are AI-built apps safe to ship?
Unchecked, you are betting your database on a demo's shortcuts. But the repeatability that creates the risk makes it checkable: 48 known patterns, 10 free Critical checks, fix prompts, and a re-scan that verifies.