Vibe coding — describing what you want in natural language and letting an AI build it — went from a meme to how a large share of new web apps get shipped. Lovable, Cursor, Bolt, v0 and Replit turn a prompt into a deployed product in an afternoon.
The problem: AI code generators are optimized to produce something that works, not something that is secure. The app loads, the demo works, the founder ships — and the exposed API key, the database with row-level security turned off, and the admin endpoint with no auth check ship right along with it.
This guide covers the real vibe coding security risks, the vulnerabilities that show up over and over in AI-generated code, a checklist you can run today, and how to scan an app before attackers do.
Why vibe-coded apps are a security risk
Traditional development has friction that quietly enforces security: code review, a senior dev who notices a hardcoded key, a deploy checklist. Vibe coding removes that friction — which is the point — but also removes the humans who used to catch the mistakes.
- The model copies insecure patterns. LLMs are trained on public code, including the millions of tutorials that hardcode keys and skip auth "for simplicity".
- The builder can't read the code. Many vibe coders are non-technical or non-security founders. If the AI writes
// TODO: add auth, nobody adds auth. - Defaults are permissive. A fresh Supabase project, an open CORS policy, a public storage bucket — the easy path is the insecure path.
- It ships immediately. There is no staging gate. The first version is the production version, exposed to the internet.
Independent studies of AI-generated code consistently find that a large fraction contains at least one exploitable vulnerability. The speed that makes vibe coding great is exactly what makes the security gap dangerous.
The 7 most common vibe coding security vulnerabilities
| # | Vulnerability | What goes wrong | Impact |
|---|---|---|---|
| 1 | Exposed secrets | API keys, DB URLs and tokens hardcoded in client code or committed .env files | Anyone can read your keys in the browser or repo and run up your bill / access your data |
| 2 | Missing or broken auth | Endpoints that return data without checking who is asking | Full data access for unauthenticated users |
| 3 | Row Level Security off | Supabase/Postgres RLS disabled, so any logged-in user can query any row | User A reads User B's private data by changing an ID |
| 4 | Secrets on the client | Service-role keys, admin logic and pricing rules shipped to the browser | Privilege escalation, price tampering, full DB access |
| 5 | No rate limiting | Login, signup and payment endpoints accept unlimited requests | Brute force, credential stuffing, cost-based abuse |
| 6 | Unvalidated input | User input passed straight into queries or commands | SQL injection, XSS, data corruption |
| 7 | Missing headers / open CORS | No CSP/HSTS, Access-Control-Allow-Origin: * on authenticated APIs | Clickjacking, token theft, cross-site abuse |
1. Exposed secrets (the #1 leak)
This is the single most common finding in vibe-coded apps. The AI puts a key where it is convenient — a Next.js client component, a committed .env, a config object shipped to the browser.
// RED FLAG: this runs in the browser
const supabase = createClient(
'https://xyz.supabase.co',
'eyJhbGciOi...SERVICE_ROLE_KEY' // service-role key on the client = game over
)
// Anything prefixed NEXT_PUBLIC_ is shipped to the browser:
const key = process.env.NEXT_PUBLIC_STRIPE_SECRET // never put a secret hereFix: only the anon/publishable key belongs on the client. Service-role and secret keys live server-side (route handlers, server actions, edge functions). Rotate any key that ever touched client code or a public repo — assume it is compromised.
2. Missing authentication
The AI builds a working CRUD app, but "working" means it returns data — not that it checks permission first.
// RED FLAG: no auth check
export async function GET() {
const orders = await db.order.findMany() // returns EVERYONE's orders
return Response.json(orders)
}Fix: every endpoint that returns or mutates data must verify the session and scope the query to the current user (where: { userId: session.user.id }).
3. Supabase Row Level Security turned off
Supabase is the default backend for a huge share of vibe-coded apps, and a fresh table has RLS disabled. With the anon key on the client (correct) but RLS off (wrong), any visitor can read and write every row. This is the classic vibe-coding data leak.
Fix: enable RLS on every table and write policies that scope rows to the user. We cover this end to end in the Supabase RLS guide.
The vibe coding security checklist
Run this before you share the link, and again before you start charging money:
- Secrets — no keys in client code; no
.envin git; only anon/publishable keys are public; secrets rotated if ever exposed. - Auth — every data endpoint checks the session; protected routes return 401/403 without a token; no admin route reachable by a normal user.
- Database — RLS enabled on every table; policies scope rows to the owner; no service-role key on the client.
- Input — all user input validated server-side; parameterized queries (no string-built SQL); output escaped.
- Rate limiting — login, signup, password reset and payment endpoints are throttled.
- Transport & headers — HTTPS enforced; CSP, HSTS and X-Frame-Options set; CORS restricted to your own origins.
- Dependencies — no known-vulnerable packages; lockfile committed.
- Monitoring — you get alerted when error rates spike (a sign of an attack in progress), not next quarter.
How to scan a vibe-coded app
| Tool | What it catches | Price |
|---|---|---|
| Nurbak | Exposed secrets, missing auth, open RLS, missing headers and more — against your deployed URL, in one pass | Free scan |
| gitleaks / TruffleHog | Secrets committed to the repo | Free (open source) |
| Semgrep | Insecure code patterns (static analysis) | Free tier |
| Snyk | Vulnerable dependencies | Free tier |
| OWASP ZAP | Runtime web vulnerabilities (DAST) | Free (open source) |
Static tools scan your code; you still need to know your live app is configured safely. Nurbak scans the deployed app for the exact issues above — exposed secrets, endpoints with no auth, tables with RLS off, missing security headers — and gives you a prioritized report. Paste your URL and get the result in seconds.
Vibe coding security FAQ
Is vibe coding safe?
Not by default. AI generators optimize for working output, not secure output. A vibe-coded app is safe only after you audit it against the checklist above — most issues are exploitable within minutes of going public.
Do I need to be technical to secure a vibe-coded app?
No, but you need to verify, not trust. Run a scanner, confirm RLS is on, confirm secrets aren't in the browser. A tool that checks the deployed app does the technical part for you.
What's the single most important fix?
Get secrets off the client and rotate anything that leaked, then enable Row Level Security. Those two cover the majority of real-world vibe-coding breaches.