The Hidden Security Cost of Vibe Coding

Last quarter we ran NeuroStrike's autonomous scanner against 200 apps built entirely through vibe coding — prompting Cursor, v0, Bolt, and Lovable without manual code review. The headline number: 94% shipped with at least one vulnerability we could exploit to steal data, escalate privileges, or take over accounts. That's not a theoretical risk score. That's a working proof-of-concept exploit for nearly every app in the set.

What We Mean by 'Vibe Coding'

The term comes from Andrej Karpathy's February 2025 post: you describe what you want in natural language, the AI writes the code, and you mostly accept the output. It's a legitimate productivity multiplier. A solo developer can scaffold a SaaS in a weekend. But every abstraction has a cost, and for vibe coding that cost is security context the LLM never had.

LLMs are trained on public repositories. GitHub's own data shows that 40% of code suggestions from Copilot reproduce patterns flagged by CodeQL. The models aren't malicious — they're doing exactly what they were trained to do: predict the most likely next token. Unfortunately, "most likely" often means "most common," and the most common patterns in open-source code are not the most secure.

The Testing Methodology

We selected 50 apps from each of four platforms: Cursor (with Claude/GPT-4), Vercel v0, StackBlitz Bolt, and Lovable. All were publicly deployed. We ran each through a three-phase assessment:

1. Automated reconnaissance: subdomain enumeration, tech stack fingerprinting, exposed endpoints
2. Agent-driven exploitation: NeuroStrike's autonomous agents attempted auth bypass, injection, IDOR, and SSRF chains
3. Manual verification: our team confirmed each finding to eliminate false positives

Finding #1: Hardcoded Secrets in Client Bundles

47% of tested apps leaked API keys, database connection strings, or service tokens in client-side JavaScript bundles. This isn't a new problem, but vibe coding makes it dramatically worse. When you tell an AI "connect to my Supabase database," it writes the most straightforward code:

// Generated by AI — ships to the browser
const supabase = createClient(
  "https://xyzproject.supabase.co",
  "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6..." // anon key with RLS bypassed
);

The fix requires understanding the distinction between server and client environments — something the AI won't enforce unless you explicitly prompt for it:

// Server-only: use environment variable, never bundle
import { createServerClient } from "@supabase/ssr";

export function createClient() {
  return createServerClient(
    process.env.SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!,
    { cookies: { /* ... */ } }
  );
}

Finding #2: Broken Access Control Is Universal

83% of apps with any form of multi-tenancy had at least one IDOR (Insecure Direct Object Reference). The pattern is predictable: the AI generates CRUD endpoints that take an ID parameter and fetch the record without verifying ownership.

// AI-generated: fetches any user's data
app.get("/api/users/:id/settings", async (req, res) => {
  const settings = await db.userSettings.findUnique({
    where: { userId: req.params.id },
  });
  return res.json(settings);
});

There's no session check. No ownership validation. Change the ID in the URL and you get another user's settings. The fixed version:

// Fixed: verify the requesting user owns this resource
app.get("/api/users/:id/settings", requireAuth, async (req, res) => {
  if (req.session.userId !== req.params.id) {
    return res.status(403).json({ error: "Forbidden" });
  }
  const settings = await db.userSettings.findUnique({
    where: { userId: req.params.id },
  });
  return res.json(settings);
});

Finding #3: SQL and NoSQL Injection Persists

We expected injection to be rare in AI-generated code because ORMs dominate modern stacks. We were wrong. 31% of apps had at least one injection point, usually in search or filter endpoints where the AI concatenated user input into a raw query for features the ORM couldn't express neatly.

Prisma's $queryRaw, Drizzle's sql.raw(), and Mongoose's $where were the most common vectors. The AI reaches for raw queries when the ORM's type-safe API doesn't have a clean abstraction for fuzzy search or complex aggregations.

Finding #4: Missing Rate Limiting on Auth Endpoints

91% of apps had no rate limiting on login, registration, or password reset endpoints. An attacker can brute-force credentials at thousands of attempts per second. According to Cloudflare's 2024 threat report, credential stuffing accounts for 30% of all login traffic on the internet. Without rate limiting, vibe-coded apps are low-hanging fruit.

What This Means for Developers

Vibe coding isn't going away — and it shouldn't. The productivity gains are real. But treating AI-generated code as production-ready without security review is like deploying to AWS without IAM policies. The model doesn't know your threat model, your compliance requirements, or your data sensitivity.

Every AI-generated app needs a security review before it touches real users. Not a manual audit — an automated, adversarial assessment that tests for the specific patterns LLMs get wrong.

We built NeuroStrike's vibe scan specifically for this: point it at your deployed app, and it runs the same agent-driven exploitation our research team used in this study. You get a prioritized list of real exploits, not a wall of informational findings. The median scan time is 12 minutes.

The Bottom Line

AI coding tools give you speed. They don't give you security. The 200-app dataset made this clear: the classes of vulnerabilities haven't changed, but the volume and consistency have. When every AI writes the same insecure patterns, every AI-generated app is vulnerable in the same ways. That's actually good news for defenders — it means automated testing can catch the majority of issues before attackers do.