“Is my vibe-coded app secure?” is the right question, and the honest default answer is not yet. AI coding tools optimise for the app working, not for the app being safe when someone hostile shows up. This is the checklist we run on every AI-built app before it gets real users — written so you can run most of it yourself in an afternoon.
45%
of AI-generated code samples failed OWASP Top-10 benchmarks (Veracode)
2.74×
higher rate of XSS vulnerabilities in AI-generated code (CodeRabbit)
48%
of developers always review AI output, though 96% say they don’t fully trust it (SonarSource)
The 5-minute test that finds the worst problem
Create two accounts. Log in as A, open the browser’s network tab, do something that loads A’s data, and copy that request. Now replace A’s ID in it with B’s ID and send it again. If B’s data comes back, your app has no authorisation — anyone can read anyone’s records by changing a number. This single test finds more real vulnerabilities in vibe-coded apps than any scanner we run.
Secrets and keys (checks 1–4)
1
No secret keys in the browser bundle
Open your deployed site, view source, search for sk_, secret, service_role, PRIVATE. Anything that starts with a public prefix (Supabase anon key, Stripe publishable key) is fine to expose; anything else is a breach waiting to happen. AI tools regularly put server keys into client code because it “works”.
2
No secrets in the git history
A key that was committed once and later deleted is still in the history. Search the full log, and if you find one, rotate it — deleting the file does nothing.
3
AI provider keys are server-side and rate-limited
If your app calls OpenAI, Anthropic or Gemini from the browser, your key is public and your bill is someone else’s playground. Move the call behind your own endpoint, cap spend at the provider, and set a per-user limit.
4
Environment variables are set per environment
Your production app should not be pointed at the same database, Stripe account or email sender as your testing. One shared .env is the most common way a test run emails real customers.
Access control (checks 5–8)
5
Row-level security is on for every table
Supabase, Firebase and similar backends are secure only when their rules are. AI-generated projects frequently ship with RLS disabled or with a policy that reads true — which means every logged-in user can read and write every row. Check every table, not just the obvious ones.
6
Every endpoint checks ownership, not just login
This is the 5-minute test above, applied to every route. “Is the user logged in?” is authentication. “Does this record belong to this user?” is authorisation. AI code is consistently good at the first and bad at the second.
7
Admin functions aren’t hidden, they’re protected
A hidden /admin route with no server-side role check is public. Check that role verification happens on the server for every admin action, not just in the UI that shows or hides the button.
8
Password reset and email verification can’t be abused
Reset tokens expire, can only be used once, and don’t reveal whether an email exists. Signup requires verification before the account can do anything expensive.
Input, output and abuse (checks 9–12)
9
Server-side validation on every write
The form validating in the browser is a UX feature. Anyone can send a request without the form. Every create and update must validate the shape, size and type of the data on the server.
10
User content is escaped, never rendered raw
Search your code for dangerouslySetInnerHTML, innerHTML, v-html or |safe. Every occurrence that touches user content is a cross-site scripting hole — the vulnerability category AI code gets wrong nearly three times as often as humans.
11
Rate limits on anything that costs money or sends messages
Signup, login, password reset, contact forms, anything that triggers email, SMS or an AI call. Without limits, a script will run it ten thousand times overnight, and you’ll find out from the invoice.
12
File uploads are restricted and stored privately
Type and size limits enforced on the server, files stored outside the public web root or in a private bucket, served through signed URLs. “Anyone with the link” is not private.
Dependencies and operations (checks 13–15)
13
Dependency audit, including packages that don’t exist
Run npm audit or the equivalent. Then look at the list for packages you’ve never heard of — AI tools occasionally invent plausible-sounding names, and attackers register those names on purpose.
14
You’d know if something went wrong
Error tracking and an alert that reaches a human. Security incidents in prototypes are discovered by customers, months later, because nobody was looking.
15
Backups exist and you’ve restored one
The response to “we were breached” or “the AI ran a migration that dropped the table” is a restore. If you’ve never tested one, you don’t have a backup — you have a hope.
What to do with your results
If you failed checks 1, 3, 5 or 6, treat it as urgent — those are the ones that get exploited automatically by bots scanning for exactly these patterns. Rotate keys first, then lock down access, then everything else. Failing the rest is normal for a prototype and fixable in a hardening pass.
This security list is the first half of our broader 12-point vibe-coded prototype audit, which adds correctness and operability checks and ends with a harden-or-rebuild verdict. If the app is already broken rather than just insecure, start with what to do when your vibe-coded app breaks. If it’s connecting AI to business systems through MCP, securing MCP in production covers that layer.
FAQ
Is vibe coding safe for a real product?
The output is safe once it has been reviewed and hardened by someone who knows what to look for. The risk isn’t the tool; it’s shipping unreviewed output to users who’ve trusted you with data or money.
Can I just ask the AI to “make it secure”?
You can, and you should ask for specific checks by name (RLS policies, ownership checks, server-side validation). But the tool will report success whether or not it’s true. Verification — the two-account test, reading the policies — has to be done by a person.
How long does a security hardening pass take?
For a typical AI-built SaaS prototype, the diagnostic is a day or two and the fixes usually fit in one to three weeks, depending on how many endpoints exist. Rotating exposed keys should happen the same day you find them.
Do I need a penetration test?
Not before the basics. A pen test on an app that fails check 6 will just produce a long report saying so. Fix this list first, then consider a professional test once you have paying customers or handle sensitive data.
Go deeper on the checks above: Supabase RLS for vibe-coded apps (check 5), what to do when you’ve leaked an API key (checks 1–3), and cost control and prompt injection for AI features if the app calls a model.
Want us to run the checklist for you?
Fixed-scope security review of your AI-built app: a prioritised findings list within days, the urgent fixes done first, and a clear quote for the rest.
Book a Security Review →
