We ran VibeScan on 50 real, production apps built with AI coding tools. The results were worse than we expected.
89% had at least one critical or high-severity security issue.
This post breaks down exactly what we found, which tools produced the most issues, and what you should check in your own app right now.
The sample
All 50 apps were:
- Publicly accessible (live on the internet)
- Built with one of: Lovable, Bolt, Cursor, Replit, or v0
- Deployed on Vercel, Netlify, or the tool's native hosting
- Run by founders or indie hackers (not enterprise teams)
We didn't cherry-pick bad apps. We picked the first 50 apps we could identify as vibe-coded by searching for telltale patterns in JavaScript bundles and deployment headers.
What we found
| Issue | Apps affected | % | |---|---|---| | Supabase anon key in JS bundle | 41 | 82% | | Missing or misconfigured CORS | 38 | 76% | | No Strict-Transport-Security header | 44 | 88% | | No Content-Security-Policy | 47 | 94% | | Missing X-Frame-Options | 39 | 78% | | Admin routes without auth | 7 | 14% | | Service role key exposed | 3 | 6% |
The most alarming finding: 3 apps had their Supabase service role key in the JavaScript bundle. The service role key bypasses Row Level Security entirely. Anyone who found it had full read/write/delete access to those databases.
Which tools had the worst numbers
| Tool | Critical issues avg | High issues avg | |---|---|---| | Lovable | 2.3 | 1.8 | | Bolt | 2.1 | 1.6 | | Replit | 1.9 | 2.1 | | v0 | 1.2 | 1.4 | | Cursor | 0.8 | 1.1 |
Cursor apps generally fared better because Cursor users tend to be more technical. Lovable and Bolt users skew toward non-technical founders, which means the AI does more of the security work — and right now, that work is being done poorly.
The Supabase problem
82% of apps had a Supabase key visible in their JavaScript. This is partially by design — the anon key is meant to be public, because Supabase uses Row Level Security to control access at the database level.
The problem: most of these apps didn't have RLS enabled.
We tested a subset of 20 apps. Of the 16 with an exposed anon key and apparent Supabase usage, 11 returned data from the database without any authentication in the request. That means:
- No session cookie required
- No JWT required
- Just the URL and the anon key
We did not exfiltrate any data. We stopped after confirming the query returned results.
Why headers matter more than you think
94% of apps had no Content-Security-Policy. This sounds abstract, but CSP is the primary defense against cross-site scripting (XSS) attacks — the #1 vulnerability in web apps.
If an attacker finds an XSS vulnerability in your app (a common find in AI-generated input handling), CSP determines whether they can actually do damage. Without it, they can load any external script, exfiltrate session tokens, and hijack user accounts.
88% had no HSTS. This means users who visit your app over HTTP won't automatically be upgraded to HTTPS on repeat visits. On public WiFi, this enables man-in-the-middle attacks.
What makes vibe-coded apps different
Traditional developers often learn about security through code review, security training, or painful incidents. Vibe coders skip that learning curve — intentionally. The point is to ship fast.
The AI tools don't fill the gap. We tested prompting Lovable, Bolt, and Cursor to "build a secure login system." None of them:
- Enabled RLS by default
- Added security headers
- Set a restrictive CORS policy
They do what you ask. Security is invisible when it's missing, so nobody asks for it.
What to do right now
- Run VibeScan on your app (it's free, takes 60 seconds)
- Enable RLS on every Supabase table — even if you think it's low risk
- Add security headers — X-Frame-Options, HSTS, CSP at minimum
- Fix your CORS policy — replace
*with your actual domain
The good news: most of these issues have straightforward fixes. The AI tools that created the problems can fix them too — they just need to be asked explicitly.
Methodology: All scans were performed between April and May 2025. We notified the 3 founders with exposed service role keys directly before publishing this post.