Vibe Coding Security Risks: A Field Guide to Shipping AI-Generated Apps Without Getting Pwned
Vibe Coding Security Risks: A Field Guide to Shipping AI-Generated Apps Without Getting Pwned
TL;DR — Vibe coding (shipping apps written mostly by AI assistants like Lovable, Cursor, v0, Bolt, or Claude Code) is fast, but the resulting codebases inherit a predictable set of security vulnerabilities: leaked API keys, missing Row-Level Security, broken auth flows, unvalidated user input, and outdated dependencies. The fix is not "stop vibe coding" — it is to run an automated security scanner (SAST, dependency, secrets, and DAST) on every meaningful change, before users touch the app.
---
What is vibe coding, and why does it create new security risks?
Vibe coding is the practice of building software by describing what you want in natural language and letting an AI agent write, edit, and wire up the code for you. Andrej Karpathy coined the term in early 2025, and tools like Lovable, Cursor, Replit Agent, Bolt, and v0 turned it into a daily workflow for hundreds of thousands of builders.
The security problem is not that AI writes bad code. The problem is what AI optimizes for and who is reviewing the output:
The result: a large, growing population of public-facing apps that look polished but leak data the moment a curious attacker opens DevTools.
The 7 most common vibe coding security vulnerabilities
Based on patterns we see across thousands of AI-generated codebases scanned through Scanbee and from public incident write-ups (Lovable, Replit, and Supabase-backed apps in 2024–2025), these are the recurring offenders:
1. Exposed secrets in client-side code
AI assistants love import.meta.env.VITE_OPENAI_API_KEY because it "just works." Anything prefixed with VITE_, NEXT_PUBLIC_, or PUBLIC_ ends up in the JavaScript bundle that ships to every browser. Anyone can open the Network tab and copy your OpenAI, Stripe, Resend, or Anthropic key.
Fix: Move every third-party API call behind an edge function or server route. The only key that belongs in the browser is your project public anon key.
2. Missing or misconfigured Row-Level Security (RLS)
Supabase and other Postgres-backed BaaS platforms ship with RLS disabled by default on new tables. AI agents will happily create a messages or invoices table, wire up a working UI, and never enable RLS. Result: any authenticated user can read every other user data.
Fix: Enable RLS on every table that holds user data, and write a policy that restricts rows to auth.uid() = user_id. Test it from a second account before shipping.
3. Role checks stored on the user record
A common AI pattern is to add an is_admin boolean to the profiles or users table and gate the admin UI on it client-side. Two problems: (a) the client can flip a state variable, and (b) if RLS allows the user to update their own profile row, they can grant themselves admin. Use a separate user_roles table and a SECURITY DEFINER has_role() function, checked on the server.
4. Broken authentication flows
Email confirmation disabled "to make testing easier" and never re-enabled. Password reset endpoints with no rate limit. JWTs stored in localStorage and never rotated. OAuth callbacks that trust a redirect_uri from the query string. AI-generated auth almost always needs a second pass.
5. SQL injection and command injection in edge functions
When an AI writes a function that takes a user-supplied string and interpolates it into a SQL query or a shell command, you have a remote code execution waiting to happen. Always parameterize SQL, and never pass user input to a shell with shell=True.
6. Outdated and vulnerable dependencies
AI agents pin whatever version was popular when their training data was cut. Six months later your lockfile is full of CVEs in axios, next, vite, or transitive dependencies you have never heard of.
Fix: Run a Software Composition Analysis (SCA) scanner like Trivy or npm audit weekly, and patch criticals within 48 hours.
7. CORS set to wildcard and CSP missing entirely
To "fix the CORS error," the AI will set Access-Control-Allow-Origin: * on every edge function. Combined with credentialed requests, this is a free CSRF on your API. Set the allowed origin to your actual domain.
What can attackers actually do with these vulnerabilities?
This is the question we hear most often from founders: "OK, but realistically — what can someone do?" Honest answers:
| Vulnerability | Realistic attacker outcome |
|---|---|
| Exposed OpenAI / Stripe / Resend key | Drain your account balance in hours; you get the bill |
| Missing RLS on user data | Bulk-download every user messages, files, invoices |
| is_admin on profile table | Grant themselves admin, delete or exfiltrate the whole DB |
| Broken password reset | Take over any account by email enumeration |
| SQL / command injection | Full database dump, or remote code execution on your server |
| Vulnerable dependency | Depends on the CVE — often RCE or auth bypass |
| Wildcard CORS | Steal session tokens via a malicious site the user visits |
None of these are theoretical. All of them have happened to publicly-named vibe-coded apps in the last 12 months.
How to scan a vibe-coded project for vulnerabilities
You need four scanner classes — running one is not enough, because each one finds a different category of bug:
1. SAST (Static Application Security Testing) — reads your source code and flags injection, auth, and crypto bugs. Tools: Opengrep, Semgrep, CodeQL.
2. SCA (Software Composition Analysis) — checks your package.json / requirements.txt against CVE databases. Tools: Trivy, npm audit, Dependabot.
3. Secrets scanning — searches the repo and the bundled JS for leaked API keys. Tools: Trivy, Gitleaks, TruffleHog.
4. DAST (Dynamic Application Security Testing) — hits the running app like a real attacker would, looking for IDOR, XSS, broken auth. Tools: OWASP ZAP, Nuclei.
The pragmatic stack for a solo vibe coder is to wire all four into CI so that every push gets scanned automatically, and you only have to read the report when something fails. That is exactly what Scanbee does — connect a GitHub repo or a live URL, get triaged findings in minutes, no security background required.
Vibe coding security checklist (copy this into your project README)
VITE_ / NEXT_PUBLIC_ env var holds a third-party API keynpm audit / Trivy run weekly, criticals patched within 48 hoursFrequently asked questions
Is vibe coding safe for production apps? Yes, if you treat the AI as a fast junior developer and put guardrails around its output — automated scanning, code review on auth and payments, and a real production checklist before launch.
Which AI coding tool produces the most secure code? Differences between Lovable, Cursor, v0, Bolt, and Claude Code are smaller than people think. All of them ship vulnerable code by default if you do not ask for security. All of them can be steered toward secure patterns if you do.
Do I need a security engineer to ship a vibe-coded app? No. You need an automated scanner that runs on every change and explains findings in plain English. The economics of solo founders make manual pentesting unrealistic for most apps until you have meaningful revenue.
How often should I scan a vibe-coded project? Every push for SAST and secrets (it is free and instant). Weekly for SCA and DAST. Re-scan immediately after touching auth, payments, or any code that handles user data.
What is the single highest-ROI security action a vibe coder can take today? Move every third-party API key out of the browser bundle. That one change kills the most common and most expensive failure mode in the entire vibe-coding ecosystem.
---
Scanbee is built specifically for this audience: founders, designers, and indie hackers shipping AI-generated apps who need enterprise-grade security scanning without enterprise overhead. Start a free scan — connect a repo or URL and get triaged findings in under five minutes.
