Vibe Coding Security: Real Risks, Real Incidents and a Pre-Launch Checklist

Why vibe-coded apps leak

AI models write code that works, not code that defends itself. In Veracode’s 2025 test of more than 100 models on 80 security-sensitive coding tasks, the generated code contained an OWASP Top 10 weakness in 45% of cases, and failed to defend against cross-site scripting in 86% of relevant samples (source: veracode.com). Newer models write more code that compiles; Veracode found security pass rates did not improve at the same pace.

Vibe coding adds three multipliers. Builders often cannot read the code, so nobody reviews it. Browser builders wire the front end straight to the database, so one missing policy exposes everything. And success comes fast: an app built in a week can have thousands of users before anyone looks at its access rules. The upside is that the mistakes are the same few every time, which makes them checkable.

Real incidents, and the lesson in each

Hosting is part of the risk too. Yuanlin Lin’s Zeabur, a deployment platform repositioned for the vibe-coding era, announced it would shut down after two security breaches in 2026 (sources: zeabur.com, cybernews.com). Keep your own backups and your own copy of the code, whatever platform you build on.

Checklist 1: authentication and access control

“Logged in” and “allowed to see this” are different checks, and AI code often does only the first, or only hides a button in the UI. Every check must happen on the server.

• Use a real auth provider (Supabase Auth, Clerk, Firebase Auth, Auth.js). Never let the AI invent password storage or session tokens.
• Check the session in every API route and server action that reads or writes private data, not just in page components.
• Test with two accounts. Log in as user A, copy the ID of one of user B’s records into a URL or API call, and confirm you get nothing back.
• Roles live on the server. An “isAdmin” flag in the browser or in a JWT the client can edit is not a permission.
• Consider a proven starter for anything with teams or billing. Boilerplates such as Jonathan Wilke’s supastarter ship authentication, billing and multi-tenancy that thousands of developers have already exercised (source: supastarter.dev).

Checklist 2: Supabase row-level security

Lovable, Bolt and many Cursor projects use Supabase, which exposes your database through an API using a public “anon” key that is meant to be in the browser. That is safe only if row-level security (RLS) is on and every policy is correct (sources: supabase.com, supabase.com). The service_role key bypasses RLS entirely and must never reach the browser or an AI agent with access to untrusted input.

1. Open the Supabase dashboard’s security advisor and fix every “RLS disabled” and “policy allows all” warning.
2. For each table, write down who should read, insert, update and delete, then compare with the policies.
3. Test from the browser console with the anon key while logged out, then as a second user.
4. Make storage buckets private unless files are meant to be public, and add policies for them too.

-- 1. Turn RLS on for every table in the public schema
alter table public.notes enable row level security;

-- 2. Owners can read their own rows
create policy "owner can read" on public.notes
  for select to authenticated
  using ( (select auth.uid()) = user_id );

-- 3. Owners can insert rows only for themselves
create policy "owner can insert" on public.notes
  for insert to authenticated
  with check ( (select auth.uid()) = user_id );

-- 4. Owners can update / delete only their own rows
create policy "owner can update" on public.notes
  for update to authenticated
  using ( (select auth.uid()) = user_id )
  with check ( (select auth.uid()) = user_id );

create policy "owner can delete" on public.notes
  for delete to authenticated
  using ( (select auth.uid()) = user_id );

-- Red flags to search for in existing policies:
--   using ( true )          -> anyone can read
--   to anon / to public     -> logged-out visitors included
--   no policy + RLS off     -> table fully open via the anon key

Founders building on Supabase include Brian Shin, whose Once app lists Supabase and Claude Code in its stack, and Prajwal Tomar, whose MVP agency pairs Lovable with Supabase. If your app has a table of users’ private content, assume the incident table above applies to you until you have tested it.

Checklist 3: secrets and API keys

• Anything prefixed for the browser is public. In Next.js that is NEXT_PUBLIC_, in Vite VITE_. Only publishable keys belong there.
• Call paid APIs from the server. An OpenAI or Anthropic key in front-end code will be found and spent by strangers.
• Set hard spending limits on every AI, email, SMS and maps provider, plus usage alerts.
• Scan the repo history, not just the current code. GitHub secret scanning or tools like gitleaks catch keys committed in a past version (source: docs.github.com).
• Rotate any key that was ever exposed, even briefly. Deleting the line does not un-leak it.
• Don’t paste production secrets into chats with AI tools; use environment variables and placeholder values.

Checklist 4: prompt injection and AI agents

Prompt injection is the top risk in OWASP’s list for LLM applications: text from a user, a web page, an email or a document that the model treats as instructions (source: genai.owasp.org). It matters in two places.

In your app’s AI features:

• Put no secrets or other users’ data in the system prompt; assume users can extract it.
• Never execute model output as code or SQL, and never render it as raw HTML.
• Give tools the least privilege: a support bot can read the current user’s orders, not every order.
• Require a human click for anything irreversible the AI proposes (refunds, emails, deletes).

In your coding agent:

• No production credentials in the agent’s environment; use a dev database and read-only modes where offered.
• Install only MCP servers you trust and keep your editor or CLI updated (CurXecute was fixed by an update).
• Don’t combine private data, untrusted content and a way to write back in one agent session.
• Use guardrails that stop the agent from cheating. Kitze’s Zero To Shipped kit added lint rules and a no-disable policy specifically to stop agents silencing errors to finish a task (source: zerotoshipped.com).

Checklist 5: dependencies and invented packages

AI models sometimes recommend packages that do not exist. A USENIX Security 2025 study generated 2.23 million package references from 16 models and found 19.7% were hallucinated, with open-source models far worse than commercial ones; many invented names repeated across runs, which makes them predictable targets (sources: usenix.org, csoonline.com). Registering those names with malware is called slopsquatting.

• Before installing, look the package up on npm or PyPI: real repo, recent releases, meaningful downloads.
• Add a rule to your agent’s rules file: name every new package and wait for approval.
• Commit the lockfile and run npm audit / pnpm audit regularly; enable Dependabot or Renovate.
• Prefer fewer dependencies. Plenty of profitable indie apps run on a deliberately small stack.

Checklist 6: payments, abuse and operations

• Payments: use hosted checkout (Stripe Checkout, Lemon Squeezy, Paddle). Decide price and entitlement on the server and verify webhook signatures. Never trust a price or a “paid: true” sent by the browser.
• Abuse: rate-limit sign-up, login, password reset, AI and email endpoints; add a CAPTCHA or email verification where bots would profit.
• Backups: turn on automatic backups and restore one once, so you know it works.
• Separation: a dev project and a prod project with different keys. Agents work in dev.
• Plan for a leak: error tracking, logs you can search, and a way to email every user.

Sensitive categories raise the bar. If your app handles health data, children, money or intimate content, as Alex Slater’s QUITTR does, pay for a human security review before you scale marketing. It costs far less than the incident.

The 30-minute pre-launch audit

Run this list before launch and after any change to auth, payments or the database. Pair it with the security review prompt in our vibe coding prompts guide, which asks your AI tool to report findings with file and line numbers.

PRE-LAUNCH SECURITY CHECKLIST

Access
[ ] Every page/API route/server action with private data checks the session on the server
[ ] User A cannot read or edit user B's data (test with two accounts + the browser network tab)
[ ] Admin features check a role on the server, not a hidden button

Database
[ ] RLS enabled on every table; no "using (true)" on private tables
[ ] service_role / admin keys only on the server, never in the browser bundle
[ ] Storage buckets private unless they must be public

Secrets
[ ] No keys in client code, the repo history, screenshots or logs (run a secret scanner)
[ ] Separate dev and prod keys; rotate anything that was ever exposed
[ ] Spending caps on every paid API (AI, email, SMS, maps)

Input and AI
[ ] Server-side validation on every form and API body
[ ] Rate limits on sign-up, login, password reset, AI and email endpoints
[ ] AI features: system prompt has no secrets; model output is never executed or rendered as raw HTML; tools are least-privilege

Dependencies
[ ] Every package exists, is maintained and is the one you meant (no typo or invented names)
[ ] Lockfile committed; audit run (npm audit / pnpm audit)

Payments
[ ] Prices and entitlements set on the server; webhooks verified with the signing secret

Operations
[ ] Agents never have production write access
[ ] Automatic backups you can restore, tested once
[ ] Error tracking and a way to contact users if something leaks

If the audit turns up more than you can fix, that is normal and fixable: freelance developers now specialise in hardening vibe-coded apps (see vibe coding jobs). And before you build, check our Can I vibe code it? pages, which flag the security-sensitive parts of common app types.