Example finding How it works Coverage PENTEST METHODOLOGY DOCS PRICING FAQ MCP CONTACT LOG IN SIGN UP →

Vibe Coding Vulnerabilities

Across 1,400+ scanned apps built with Lovable, Cursor, Bolt, Replit, Claude Code, v0, Devin, and Windsurf, the same 14 vulnerability patterns recur. They aren't tool-specific bugs - they're how AI coders model the world. Here are the patterns, why they ship, and the fix.

The 14 vibe coding vulnerabilities

These aren’t bugs in any specific AI coding tool. They’re patterns in how AI models generate code, and they appear whether the developer used Lovable, Cursor, Bolt, Replit, Claude Code, v0, Devin, or Windsurf.

Critical (whole-database / account-takeover risk)

1. Missing Row Level Security on Supabase / Firebase

A common critical finding. AI generates database tables and routes but skips the row-level security policy. The Supabase anon key (public, ships in every browser) becomes effectively a read/write key for the whole database.

Fix: Firebase Security Rules: 12 Common Mistakes for Firestore. For Supabase, enable RLS on every table and write policies matching your auth model.

2. Hardcoded API keys in frontend bundle

Stripe secret keys, OpenAI API keys, AWS credentials, Firebase service-account JSON - placed directly in source files that get bundled and shipped to every visitor’s browser.

Fix: Token Leak Checker finds these. Move every secret to server-only environment variables; for client-side variables, use the public-prefix convention (NEXT_PUBLIC_, VITE_).

3. BOLA / IDOR on CRUD endpoints

GET /api/invoice/:id checks the user is logged in but doesn’t check the user owns invoice :id. Anyone with a valid session can read any invoice.

Fix: Add ownership check on every CRUD endpoint with a path parameter. Match req.user.id to resource.owner_id before returning or modifying.

High

4. Over-permissive CORS

Access-Control-Allow-Origin: * set to silence development errors and shipped to production. When combined with Allow-Credentials: true, any origin can read authenticated responses.

Fix: Allowlist origins via env var. Reject * for any endpoint with credentials.

5. Missing input validation

Generated handlers trust user input - no length checks, no type validation, no allowlist constraints. Opens XSS, SQL injection, command injection, server-side request forgery.

Fix: Add Zod (or framework-equivalent) validation to every endpoint. Reject malformed requests with 400.

6. SQL injection via string concatenation

Despite training data showing parameterized queries, AI still produces db.query(\SELECT * FROM users WHERE email = ‘${email}’`)` for “complex” queries.

Fix: Replace template-literal SQL with parameterized queries. ORMs help but don’t fully prevent - audit raw query escapes.

7. Verbose error handlers exposing internals

catch (e) { res.json(e) } ships database error messages, stack traces, and internal file paths to attackers.

Fix: Structured error handler. Log full error server-side. Return generic message + correlation ID to client.

8. Webhooks without signature verification

Stripe, Slack, GitHub all sign webhooks. AI-generated handlers trust whatever request arrives. Attackers can replay or forge webhook events to trigger billing actions, send messages, or commit code.

Fix: Verify the provider’s documented signature. Use constant-time comparison. Reject unsigned or invalid-signature requests with 401.

High-Medium

9. JWT signature skipped or wrong algorithm

jwt.decode() (unverified) used instead of jwt.verify(). Or none algorithm accepted. Or signing secret left at default. Each makes tokens trivially forgeable.

Fix: Always jwt.verify() with server-side secret. Reject none algorithm. Verify iss, aud, exp explicitly.

10. Missing rate limiting

Auth endpoints, password reset, expensive queries shipped without rate limits. Enables credential stuffing, brute force, and resource exhaustion.

Fix: Rate-limit auth endpoints per IP (for example 5 per minute) and the general API more loosely (for example 100 per minute). Use express-rate-limit or Cloudflare/upstream rate limits.

Medium

11. Self-editable role / permission fields

User update endpoints accept arbitrary fields, including role or permissions. A logged-in user can PATCH /api/users/me {"role": "admin"} and escalate.

Fix: Allowlist updatable fields per endpoint. Role/permission changes go through a separate admin-only endpoint.

12. Open storage buckets

S3, Supabase Storage, Firebase Storage buckets created without access rules. Any object readable or writable by anonymous users.

Fix: Set bucket-level access controls. For Supabase, RLS policies on the storage table. For S3, block public access at bucket level.

13. Debug routes shipped to production

/admin, /_debug, /health/full, /swagger reachable without auth. Common when AI generates scaffolding during development and the developer forgets to gate.

Fix: Audit every route. Remove or auth-gate anything not intended public. Use environment-based route registration (/swagger only in dev).

14. Hallucinated dependencies

AI suggests package names that don’t exist on npm or PyPI. Attackers register the hallucinated names with malicious code (slopsquatting). When the dev runs install, malware loads.

Fix: Package Hallucination Scanner verifies every dependency before install. Pin versions in lockfile.

Why AI keeps producing these patterns

Three structural reasons:

1. Training data is biased toward functionality. Every “build me a CRUD app” example online shows the auth check; few show the ownership check. Models learn what they see most.

2. AI optimizes for what was prompted. “Add a delete endpoint” produces a delete endpoint. Security is rarely in the prompt; the model doesn’t add it without being asked.

3. AI lacks attack-surface awareness. A human reviewing one file remembers the sibling files. AI sees the file in isolation, secures it locally, and the inconsistency across files becomes the vulnerability.

The reliable fix is downstream: a security gate in CI that catches what the prompt didn’t.

Prevalence by tool

The patterns are tool-agnostic. The most common critical finding by tool:

Tool Most common critical finding
Lovable Missing RLS on Supabase tables
Bolt Hardcoded API keys in frontend bundle
Cursor BOLA on CRUD endpoints
Claude Code Missing rate limiting on auth
v0 Server actions without auth
Replit Public databases and exposed .env
Devin Hardcoded credentials and missing auth
Windsurf Hardcoded secrets in frontend

How to test for all 14 in one pass

Vibe Code Scanner tests for all 14 patterns against your deployed app. Each finding ships with the matching fix prompt for paste-into Cursor / Claude Code / Lovable.

How to prevent these patterns

Four layers:

  1. Prompt explicitly. Ask for input validation, auth checks, parameterized queries every time.
  2. Required PR review for every AI-generated commit. Reviewers trained on this list.
  3. CI security gate. Static scan + dynamic scan must pass before merge.
  4. Dynamic scan on every deploy. The deployed-app scan catches what review missed.

Common questions

What are vibe coding vulnerabilities?
Vibe coding vulnerabilities are the security gaps that recur in apps built primarily through AI coding tools. They aren't bugs in any specific tool - they're patterns in how AI models generate code. The same 14 patterns appear whether you use Lovable, Cursor, Bolt, Replit, Claude Code, or v0.
Why does AI-generated code have predictable vulnerabilities?
Three reasons. First, training data is biased toward functionality over security - models see far more 'login example' than 'secure login example.' Second, AI optimizes for what was asked; security is rarely the prompt. Third, AI lacks awareness of the wider attack surface, so it secures one route while leaving the sibling open.
How are vibe coding vulnerabilities different from regular bugs?
Regular bugs are inconsistent - every dev makes different mistakes. Vibe coding vulnerabilities are predictable. The same 14 patterns ship across apps, tools, and developers. That's bad for security but good for scanning: a finite list of patterns is testable in under 60 seconds.
Can I just prompt the AI to write secure code?
Partially. Explicit prompts ('add input validation, use parameterized queries, check ownership before returning resources') help but don't eliminate the patterns. The AI will still miss patterns it wasn't reminded to add. The reliable fix is a security gate in CI that catches what the prompt didn't.
Which vibe coding vulnerabilities are most severe?
By incident count: missing Row Level Security on Supabase / Firebase tables (whole-database leakage), hardcoded API keys in frontend bundles (account takeover, billing fraud), and BOLA on CRUD endpoints (cross-user data access). These three account for ~60% of critical findings across all vibe-coded apps we've scanned.
Are paid tools (Cursor Business, Windsurf Enterprise) more secure?
Enterprise tiers add platform controls (admin policy, audit, SOC 2) but the underlying model still produces the same code patterns. Enterprise security depends on workflow: required PR review, CI security gate, dynamic scan on deploy. Plan tier doesn't change that.

Scan your vibe coded app

Paste your live URL. We probe the failure modes this stack ships most often - keys, auth, and open data. Results in under 60 seconds.

14-day free trial · No credit card · Cancel anytime

START FREE SCAN →