I Scanned 100 AI-Built Apps. Here's Which Tools Ship the Most Vulnerabilities.

We ran VibeShield against 100 apps built with Cursor, Bolt.new, and Lovable. The results reveal which vulnerabilities each tool consistently produces — and exactly what to fix after every generation session.

Three months ago, I had a question I couldn't shake: does the AI coding tool you pick actually change how secure your app ends up? Everyone talks about speed and UX — "Cursor feels more natural," "Bolt ships faster," "Lovable's templates are cleaner." Nobody was talking about the security fingerprint each tool leaves on the code it generates.

So I stopped wondering and started scanning. We ran VibeShield against 100 publicly deployed apps — roughly a third built with Cursor, a third with Bolt.new, and a third with Lovable. Not curated samples. Not hand-picked showcases. Just apps we found in the wild, built by real developers who shipped what the AI gave them.

Here's what we found. None of it is pretty.

Methodology

We didn't cherry-pick. Every scanner result used the same checks: exposed API keys in client bundles, missing RLS policies on Supabase tables, CSP header configuration, CORS header permissiveness, cookie flag completeness, and common framework-level misconfigurations. We categorized findings by severity — critical (exposed live keys), high (missing CSP, missing HttpOnly), medium (missing X-Frame-Options), low (missing Referrer-Policy).

The 100 apps were identified through a combination of public portfolio links, "built with X" showcase pages, and social media posts where developers shared their AI-built projects. We excluded apps that were obviously incomplete or non-functional.

The Vulnerability Density Table

This is the table that should worry you. It shows how often each vulnerability class appeared across apps built with each tool:

Figure 1: Vulnerability density across Cursor, Bolt.new, and Lovable — percentage of apps exhibiting each vulnerability class.

Three numbers jump out: Bolt.new apps ship with exposed Supabase keys at triple the rate of Cursor apps. Lovable apps are four times more likely to have wide-open CORS. And across all three tools, CSP is essentially absent — 74% is the best number, and that's still terrible.

Cursor: Control Comes with Responsibility

Cursor is an AI-augmented IDE, not a full-app generator. You see every line before it lands. You write the prompts. The model works within your existing project structure and respects the patterns you've already established.

Where Cursor shines: Developers who know security produce more secure code because Cursor follows their lead. If your project already has CSP headers, Cursor won't remove them. If you explicitly ask for input validation, you get it. There's no "generate the whole app" step that introduces systemic vulnerabilities.

Where Cursor fails: The output depends entirely on your security awareness. Cursor won't suggest adding CSP unless you ask. It won't flag that your cookie is missing HttpOnly unless you're specifically working on cookie configuration. It generates what you request — nothing more. If you've never heard of SameSite, Cursor won't teach you about it.

The Cursor security profile: Fewer automatic vulnerabilities than the other tools, but a wider variance. Security-savvy developers produce reasonably secure code. Developers who don't know what they don't know produce the same gaping holes — just with cleaner syntax.

What Cursor users should do after every session:

1. Scan for exposed keys — Cursor sometimes suggests placeholder keys that look real enough to ship.
2. Add security headers via middleware — Cursor won't do this unless you explicitly prompt for it.
3. Check cookie configurations — especially if you integrated Supabase or NextAuth.

Bolt.new: Speed Kills (Security)

Bolt.new generates complete, deployable projects from natural language. You describe an app, and 30 minutes later you have a live URL. That speed is incredible — and it's exactly what makes Bolt the most vulnerability-dense tool we tested.

Where Bolt shines: Infrastructure-level security is solid. Bolt deploys on HTTPS by default. It handles environment variables correctly when they're properly configured. The generated code structure is modular and reasonably organized.

Where Bolt fails — badly: Bolt routinely generates Supabase client configurations with the service_role key in the frontend bundle. This isn't a subtle mistake. The service_role key bypasses Row Level Security entirely — anyone with it can read and write every table, including user data, without authentication. A quarter of Bolt apps we scanned had this key sitting in their JavaScript bundle, visible to anyone who opens DevTools.

Bolt also rarely generates RLS policies. When it does generate SQL, it creates tables without row-level security enabled. Authentication checks on API routes are inconsistent — some routes check, some don't, and the pattern isn't predictable enough to audit by hand.

The real-world example that haunts me: A Bolt-built app with 1,200 users had its Supabase service_role key exposed for two months. The developer had shipped directly from Bolt without reviewing the configuration. When we notified him, the key was already in a public GitHub repository and had been accessed by at least three different IP addresses he didn't recognize.

What Bolt users should do immediately:

1. Check your Supabase configuration. If service_role appears anywhere in your frontend code, rotate the key NOW — and then remove it from the client bundle.
2. Generate RLS policies for every table that stores user data. Don't assume Bolt handled this.
3. Add CSP, HSTS, and cookie flags. Bolt generates none of these.
4. Audit every API route for authentication checks. Don't trust the generated middleware alone.

Lovable: Consistent Structure, Consistent Gaps

Lovable uses template-based generation, which means its output is more predictable than Bolt's — but the vulnerabilities it produces are just as predictable.

Where Lovable shines: The code structure is consistent. If one API route has proper error handling, they all do. If one component uses safe DOM APIs, the pattern carries through. This makes auditing faster — you can trust patterns once you've verified them.

Where Lovable fails: CORS is the standout problem. Nearly half of Lovable apps set Access-Control-Allow-Origin: * — meaning any website on the internet can make authenticated requests to your API. Combined with missing SameSite cookie flags (29% of Lovable apps), this creates a clean path for CSRF attacks.

Lovable also has a unique RLS problem. Unlike Bolt, Lovable does generate RLS policies — but they're often too broad. We found 19% of Lovable apps with RLS policies set to USING (true), which means "this policy allows everything." It's the database equivalent of a door with a lock that doesn't engage. The policy exists, the check passes, the scanner might miss it — but it provides zero protection.

What Lovable users should do:

1. Tighten CORS. Never use * in production. Specify your exact domain.
2. Review every RLS policy. If you see USING (true), rewrite it to check auth.uid() = user_id.
3. Add CSP headers — Lovable generates none.
4. Check cookie flags. SameSite=Lax, Secure=true, HttpOnly=true on every auth cookie.

The Common Thread

No tool generates secure code out of the box. The question isn't "which tool is safe?" — it's "which vulnerabilities does my tool produce, and do I know how to fix them?"

The developers who ship secure AI-built apps all do the same thing: they run a security scan after every major generation session. They don't trust the output. They verify it.

Summary

• No AI coding tool generates secure code out of the box. The question isn't "which tool is safe?" — it's "which vulnerabilities does my tool produce, and do I know how to fix them?"
• Bolt.new apps ship with exposed Supabase service_role keys at triple the rate of Cursor apps (24% vs 8%) and rarely generate RLS policies (41% missing).
• Lovable apps are four times more likely to have wide-open CORS (Access-Control-Allow-Origin: *) at 47%, and 19% have RLS policies set to USING (true) — functionally disabled RLS with a misleading policy name.
• Cursor gives more control but depends entirely on your security awareness — it won't suggest adding CSP or fixing cookie flags unless you already know to ask.
• CSP headers are absent from 74–96% of all AI-built apps regardless of tool. The developers who ship secure code all do the same thing: they scan after every major generation session.

Found this useful? Scan your app at vibeshield.org — free, takes 30 seconds, and catches the exact tool-specific vulnerabilities described in this post.

Read next: 5 Security Headers Every Vibe-Coded App Needs — the fastest way to close CSP and cookie gaps. Also Supabase RLS Mistakes AI Coding Tools Make for fixing USING (true) and missing RLS policies.