VIBE CODING SECURITY: THE COMPLETE RISK GUIDE (2026)

What is vibe coding security?

Vibe coding security is the practice of testing and hardening applications produced by AI coding tools — Lovable, Cursor, Bolt, v0, Replit, Claude Code, GitHub Copilot, and similar. The risk profile is distinct from traditional software: the code compiles, the feature works, and the vulnerabilities are in the defaults the AI never questioned. Vibe coding security covers the gap between “it runs” and “it’s safe to ship.”

The class of bug is not new. SQL injection, broken access control, leaked secrets, missing rate limits — every item below has been on the OWASP Top 10 for a decade. What is new is the rate and pattern: an AI builder reproduces the same misconfiguration across thousands of apps because the same training data contains the same insecure example. So you don’t get a long tail of one-off CVEs; you get a small set of identical defaults shipped at scale.

Why are vibe-coded apps vulnerable?

AI models optimize for working code, not secure code. They reproduce patterns from training data without understanding your threat model. The result: apps that work perfectly in demos but expose user data, payment flows, and admin access in production.

Three structural reasons make this worse than traditional code-gen:

• The prompt is the spec, and the spec is incomplete. “Add a profile page” never says “and authorize the read by user ID.” The AI fills the gap with the default it has seen most often, which is no authorization at all.
• Working features hide broken authorization. A page that loads a profile is indistinguishable from one that loads any profile. Without a second account to test with, the bug is invisible to the founder.
• The model self-references. Once an insecure pattern lands in your file, the AI sees it on the next turn and reuses it. A single bad import becomes the codebase’s house style within an afternoon.

The rest of this page is the catalogue: each category, what AI tends to ship by default, and the one or two things you can paste back into the same AI to fix it.

What are the code generation risks in vibe coding?

Hallucinated Security Functions

AI invents non-existent security libraries or methods that look legitimate but provide zero protection. A common case: a call to bcrypt.hashSync(password) from a package the AI named secure-bcrypt that does not exist on npm — or worse, a package an attacker has now squatted on npm with the same name and a malicious payload. Spot this by grepping every dependency in your package.json against the actual registry; any package not present in the official index is either a hallucination or a supply-chain risk.

Outdated Vulnerability Patterns

AI models trained on older code reproduce deprecated patterns with known CVEs — crypto.createCipher instead of createCipheriv, request instead of undici, JWT libraries pinned to versions with alg: none bypasses. The fix is rarely complex; the work is finding them. Run npm audit and pip-audit against the AI-generated lockfile and triage anything CVSS ≥ 7.

Copy-Paste Propagation

A single insecure pattern generated early in a session gets repeated across your entire codebase as the AI references its own output. If your first endpoint skipped auth, every endpoint after it will skip auth in the same way. Audit the first three files the AI wrote — they set the convention for everything else.

Incomplete Error Handling

AI generates try / catch blocks with empty handlers or generic catches that swallow critical security errors silently. A failed authorization check that throws into a catch (e) {} becomes a successful response. Search the codebase for empty catches and catch (e) { return res.json(...) } patterns — both convert security failures into 200 OK.

What authentication risks do AI coding tools introduce?

Client-Side Auth Checks Only

AI tools often generate auth guards in React/Vue but skip server-side validation entirely. A <RequireAuth> wrapper hides the page; the API behind it is open. Anyone with curl can hit the endpoint without the wrapper ever rendering. The fix is to require the same check on the route handler — every protected route, every method, no exceptions.

Hardcoded API Keys

AI frequently embeds Supabase anon keys, Firebase configs, and API secrets directly in frontend code visible to anyone. The Supabase anon key is meant to be public, but only when RLS is on; the service-role key is never meant to ship to the browser. Use the Token Leak Checker to confirm what your bundle actually exposes.

Missing Row-Level Security

Supabase and Firebase apps built with AI rarely have proper RLS policies. Any authenticated user can read or modify any data. The default Lovable / Bolt / Cursor flow creates the table, ships the page, and never enables the policy — see the Supabase RLS misconfiguration atlas for the recurring patterns.

Weak Session Management

AI generates predictable session tokens, skips expiration logic, or stores tokens insecurely in localStorage (where any XSS reads them). Move tokens to HttpOnly cookies, set a real expiry, and rotate on privilege change. See the auth-flows pattern article for the recurring magic-link / reset-token mistakes.

How does AI-generated code expose sensitive data?

Over-Permissive CORS

AI defaults to cors({ origin: "*" }) which lets any website make authenticated requests to your API. With credentials: true on top, this is a credentialed-allow-all and one of the easiest pivots from a phishing site to your real users. Pin to your actual frontend origin, never echo the request Origin back without an allowlist. Pattern detail: CORS credentials misconfig.

Verbose Error Messages

Stack traces, database schemas, and internal paths leak to users through AI-generated error handlers. A 500 page that includes at /home/runner/app/db.ts:42 tells an attacker the runtime, the file layout, and the ORM. Strip stack traces in production; log them server-side instead.

Excessive API Responses

AI returns entire database records including sensitive fields like password hashes, emails, and internal IDs. The SELECT * habit gets baked into the API. Define an explicit response shape per endpoint and return only those fields — both safer and faster.

Unprotected Admin Endpoints

AI creates admin routes without authentication middleware, assuming the frontend will handle access control. Routes named /api/admin/* get crawled by automated scanners within hours of going live. Require an explicit role check on every admin handler, never rely on the route name as security.

What are the dependency risks of AI-generated code?

Phantom Dependencies

AI suggests packages that do not exist on npm/PyPI. Attackers register these names and publish malicious code — “slopsquatting.” Run the Package Hallucination Scanner over your package.json; any unknown name is a red flag whether or not someone has squatted it yet.

Outdated Package Versions

AI recommends specific versions from its training data that now have known security vulnerabilities. The package was correct when the model was trained; the version was current then; both are stale now. Re-run npm audit fix after every AI-generated install batch.

Unnecessary Dependencies

AI imports heavy libraries for simple operations, expanding your attack surface with code you do not need. lodash for one _.get call brings in the entire surface of that library — and every transitive dependency. Replace with native JS where the call site is one-shot.

Missing Lock Files

AI-generated projects often skip lock-file configuration, allowing dependency versions to drift silently. The version that passed your local test is not the version that ships to production. Commit package-lock.json / pnpm-lock.yaml / poetry.lock and enforce npm ci in CI.

What deployment security risks does vibe coding create?

Secrets in Source Code

Database URLs, JWT secrets, and payment keys committed to git repositories because AI put them in config files. Run git log -p | grep -E 'sk_live|service_role|AKIA' over the full history — the leak is not just in HEAD, it is in every commit that ever touched the file. Rotate every key found, then move them to a secret manager. See the poisoned CI / DevOps leak pattern for the recurring CI-side variants.

Missing HTTPS Enforcement

AI configures HTTP servers without TLS redirects, leaving data transmitted in plaintext on the first hop. Set HSTS with includeSubDomains and preload once you are confident the cert chain is stable.

Debug Mode in Production

AI leaves development flags enabled: debug logging, hot-reload endpoints, source maps exposed to users. Source maps are the worst of these — they hand an attacker your full unminified frontend. Set productionBrowserSourceMaps: false (Next.js) or the equivalent for your framework.

No Rate Limiting

AI-generated APIs have zero throttling. Attackers can brute-force login, scrape data, or run up your cloud bill. Add per-IP and per-account rate limits on auth endpoints first; expand to expensive read endpoints next. The vibe-code-scanner flags missing rate limits as a separate severity from missing auth, because the impact (DoS, credential stuffing) does not require the auth to be broken.

What business logic vulnerabilities do AI tools create?

Payment Bypass

AI implements payment flows that can be skipped by modifying client-side state or calling API endpoints directly — a “success” handler that trusts the redirect URL, not the webhook. The Stripe webhook is the only honest signal; trust the webhook, verify the signature, never grant entitlement from the redirect. Pattern detail: Stripe webhook and paid-trust.

Race Conditions

AI generates concurrent database operations without transactions or locks, enabling double-spending and data corruption. The classic shape: if (balance >= price) { balance -= price; grant() } with no lock. Two parallel requests both read the original balance and both grant. See race conditions in money paths for the recurring shapes.

Insecure Direct Object References (IDOR / BOLA)

AI uses sequential IDs in URLs without ownership checks. Users can access other users’ data by changing the ID. This is the single most common AI-generated bug after missing RLS — see BOLA in AI-generated CRUD. Test with two accounts before launch; it takes five minutes and catches most cases.

Missing Input Validation

AI trusts all user input. No length limits, type checks, or sanitization on form fields and API parameters. Mass assignment is the variant that does the most damage: User.update(req.body) accepts any field including is_admin. See mass assignment for the fix sketch.

How to triage these risks in priority order

Twenty-four findings on a launch-day report is overwhelming. The order below is what we use internally and what the solo founder pre-launch checklist follows:

1. Data layer access control — RLS / Firebase rules. Without this, every other check is moot.
2. Secrets in the bundle — leaked keys are billable damage from minute one. Rotate immediately if found.
3. BOLA / IDOR — one user reading another user’s data is the single most common breach in AI-generated CRUD.
4. Self-editable role / permission fields — escalation from any user to admin is one POST away.
5. Auth on the API, not just the UI — the route guard in React is decoration if the backend route is open.
6. Webhook trust for paid features — never grant entitlement from a redirect URL.
7. CORS + credentials — credentialed allow-all is a credential-stuffing pivot.
8. Rate limits on auth and expensive reads — credential stuffing, scraping, cloud bill.
9. Dependency CVEs and phantom packages — supply chain.
10. Source maps, debug routes, verbose errors — recon surface; raises the cost of every other attack.

Items 1–3 cost the user data. Items 4–7 escalate access. Items 8–10 raise the noise floor. Spend your first hour on 1–3, your next hour on 4–7, and budget a week of background work on 8–10.

Which AI coding tools are most affected by security risks?

Every AI coding tool produces these security risks. Full-stack tools like Lovable and Bolt that control the entire application have the highest risk because they generate both frontend and backend code. Code assistants like Cursor and Copilot have lower risk because a developer reviews each change. The severity depends on how much of the stack the tool controls:

Full-stack builders

Highest risk. Generate entire apps including auth, database, and deployment. Lovable, Bolt, v0, Replit Agent, Firebase Studio, and Base44 fall here. The defaults baked into the platform (Supabase project setup, Firebase rules, Vercel deploy config) determine the baseline; the prompt rarely overrides them.

IDE assistants

Medium risk. Generate code within existing projects but may miss security context. Cursor, Windsurf, Claude Code, and Cline. The risk profile depends on the codebase they land in: a hardened repo with linting and tests catches most issues; a fresh repo inherits whatever convention the assistant sets first.

Code completion

Lower risk. Suggest snippets but the developer controls architecture decisions. GitHub Copilot, Tabnine. The bugs here are usually copy-paste-scale: an insecure regex or eval lands once, then again, then everywhere.

The full per-tool comparison is in Lovable vs Bolt vs Cursor — same spec, different security profile.

How is vibe-coding security different from traditional AppSec?

Traditional AppSec assumes a small number of skilled engineers writing code reviewed by other skilled engineers, with a known threat model and a security-aware paved road (frameworks, linters, base images). AI-generated apps invert most of that:

• The author is the AI; the reviewer is the founder. The reviewer often does not know what an RLS policy is, let alone whether the one the AI wrote is correct.
• The defaults move the bug class. Where traditional apps tend to fail in custom code (the bespoke auth shim, the homebrew JWT), AI-generated apps fail in the boilerplate (the table without RLS, the route without auth middleware).
• The fix is in the same place as the bug. The AI that wrote the bug is the cheapest tool to fix it. Paste the finding back into Cursor / Claude Code / Lovable as a prompt, accept the change, redeploy, re-scan. The loop is faster than any human triage.
• Regression is constant. A new feature added next week may regenerate the same bug. Continuous scanning, not a one-shot pentest, is the right shape of test.

That last point is why why gapbench exists — every pattern article on this site is a reproducible failure scenario you can run against your own app, not a one-time benchmark.

FAQ

Is vibe coding inherently insecure, or is it just a defaults problem?

Mostly defaults. The AI can write secure code if you ask for it explicitly and review what it produces. The problem is the empty prompt: “build me a SaaS for X” gives the AI no security spec, so it falls back to the most common shape it has seen, which is the insecure one. Ask for RLS on every table, auth on every route, and webhook verification on every payment flow, and the output is meaningfully better.

Can I just ask the AI to “review my app for security”?

The same model that wrote the bug usually cannot see it. Self-review hits the same blind spots that produced the original code. A second model or an external scanner is the cheapest second opinion. The free scanners listed on this site are all scoped to do exactly that.

How often do these issues regress?

The data-layer and auth issues regress every time a new table or endpoint is added — call it once per feature. Header, CORS, and source-map issues regress when the deploy config changes — call it once per platform migration. Dependency CVEs regress on their own timeline as new vulnerabilities are disclosed. The cheap habit is to re-run the scanners after every deploy; the expensive one is to wait for an incident.

What does a “fix prompt” look like?

A fix prompt is the finding restated as an instruction to your AI editor. Example for a missing RLS policy on the invoices table: “Add a Row Level Security policy to the invoices table that restricts SELECT, UPDATE, and DELETE to rows where auth.uid() = user_id. Add the equivalent policy for INSERT that requires auth.uid() = user_id in the new row. Generate the SQL migration and the Supabase CLI command to apply it.” Every finding from the VibeEval scanner ships with one of these prepared.

Related Resources

Common Security Flaws

Detailed code examples of each vulnerability with fixes

Token Leak Checker

Free tool to scan for exposed API keys in your app

Vibe Code Scanner

Universal security scanner for AI-generated apps

Firebase Security Scanner

Check Firestore rules and Cloud Storage config

Node.js Security Scanner

Find Express misconfigs and dependency vulnerabilities

Is Lovable Safe?

Security analysis of the most popular AI app builder

Why gapbench

The reproducible-scenario approach behind every pattern article on this site

Find these risks in your app

VibeEval scans for every category above automatically. Paste your URL and get a security report in under five minutes — with a fix prompt for every finding, written for the AI editor that built the app.