Vibe coding security
You described an app and an AI built it. It runs, it looks great, and you're about to show it to real people. Here's the uncomfortable part nobody mentions in the demo video: the same model that nailed your UI will also, cheerfully, hand out your database keys. This is the honest, data-backed guide to what goes wrong — and how to check your app before the internet does.
Is vibe coding safe?
For prototypes and internal tools, yes. For anything with real users or real data, no — not by default. AI coding tools optimize for “it works,” not “it's safe,” so they skip the parts an attacker cares about. The answer isn't to stop vibe coding. It's to verify before you launch.
Of 144 real AI-built apps we've scanned, 0% shipped with at least one security issue.
These aren't survey numbers or someone else's study. They're live aggregates from SafeLaunch scans of real, public vibe-coded apps — updated as we scan. No raw data, no app names, just the pattern.
Most common findings
Findings by severity
By category
Live aggregate across 149 scans · updated October 22, 2026 · see the full report →
What actually goes wrong
Six failures account for nearly everything. Each one is invisible in a working demo and obvious to someone poking at it on purpose. Each comes with a 30-second tell you can check yourself.
Secrets shipped to the browser
The single most common finding. A live API key — Supabase, OpenAI, Stripe, whatever — ends up in the frontend bundle or committed to the repo, where anyone with the dev tools open can lift it. The app works perfectly; it's just also handing out the keys.
The tellOpen your deployed site, view source, and search the bundle for "key" or "sk-". If you find one, it's already public.
A database anyone can read
AI builders love Supabase, and Supabase is only safe if row-level security (RLS) is on. Tables ship without it — or with a policy of USING (true), which looks enabled and blocks nothing — so every user's data is readable, writable, and deletable by anyone who finds the endpoint.
The tellIn the Supabase dashboard, any table without the green "RLS enabled" badge is wide open.
Auth that only exists in the browser
The login gate lives in a React component, not on the server. It hides the button, not the data — change a URL or call the API directly and the "protected" route answers anyway. The demo looks locked down; the backend never got the memo.
The tellLog out, then hit a logged-in API route directly. If it returns data, your auth is decorative.
Dependencies you didn't vet
AI pulls in packages by name — and sometimes invents a plausible one that doesn't exist, which an attacker can then register and fill with malware ("slopsquatting"). Even the real packages drift into known CVEs the moment they're a few versions behind.
The tellRun a dependency audit. Anything flagged "critical" is a published exploit, not a theoretical one.
A live site with the lights left on
The code can be fine and the deployment still leaks: a publicly readable .env or .git directory, missing HTTPS or security headers, verbose error pages that print stack traces and connection strings. The attack surface isn't just the repo — it's the running app.
The tellTry loading /.env and /.git/config on your live domain. Neither should return anything.
Your users' data, quietly forwarded
Many AI-built apps pipe user input to a model provider — often several — without saying so anywhere. Not malicious, but it's a disclosure and sometimes a compliance problem, and it's the kind of thing that surfaces at the worst possible moment.
The tellList every external service your app sends user data to. If your privacy policy doesn't name them, fix that.
Each of these has a deep guide — how it happens, how to check, how to fix: browse security by issue →
Why AI builds it this way
None of this is the model being careless. It's the model being rewarded. It's trained on a world of code that mostly works, graded on whether the thing runs, and pointed at the happy path — the one where every user is polite. Security lives on the adversarial path, which the model was never asked to walk. So it reaches for the service-role key (always works), writes a database policy that blocks nothing (never fails), and trusts the frontend to enforce the rules (looks right in the preview). You get an app that is genuinely good at everything except the one thing it was never optimizing for.
Which is also why “ask the AI to make it secure” only goes so far: the reviewer has the same blind spots as the author, and it can't see your live site, your deployed environment, or your real database rules — where a lot of the damage actually lives.
Every builder leaks in its own way
The specific risks depend on how your app was built. Pick your builder for the issues it tends to produce and exactly what to check.
Check your app before the internet does
SafeLaunch scans your repo and live site in about 30 seconds — leaked keys, open databases, client-side auth, risky dependencies, live-site hardening — and gives you a prompt to paste back into your builder to fix each finding. Pass, and your app gets listed in the verified directory.
The 60-second self-check
Before you do anything else, run these five:
- View source on your live site and search the bundle for an API key. There shouldn't be one.
- Open your database dashboard — every table with user data needs row-level security on.
- Log out, then call a logged-in API route directly. It should refuse you.
- Load /.env and /.git/config on your domain. Both should 404.
- Run a dependency audit and fix anything marked critical.
Pass all five and you've cleared the failures we see most. Want the rest checked — and a fix prompt for anything that's off — run a full scan.
Vibe coding security FAQ
Is vibe coding safe?+–
Vibe coding is safe for prototypes and internal tools. For anything with real users or real data, an AI-built app is not safe by default — the assistant optimizes for "it works," not "it's safe," so the same code that renders a nice UI will happily ship your database key to the browser. The fix isn't to stop vibe coding; it's to check the app before you launch and fix what it missed.
What are the biggest security risks in vibe-coded apps?+–
Four show up again and again: (1) leaked API keys and secrets baked into the frontend or committed to the repo; (2) databases left wide open because row-level security was never turned on; (3) permission checks that run in the browser but not on the server, so anyone can skip them; and (4) vulnerable or hallucinated dependencies. All four are invisible in a working demo and obvious to an attacker.
Why do AI coding tools produce insecure code?+–
Because they're trained to make the thing run. Security is the adversarial path — what a malicious user does — and the model is rewarded for the happy path, where everyone behaves. It will reach for the service-role key because that's the one that always works, enable a database policy of USING (true) because that never blocks anything, and reuse a plausible-sounding package name that may not be the real one.
Can I just ask the AI to make my app secure?+–
Partly. Asking "review this for security issues" catches some things, but the model has the same blind spots that produced the code, and it can't see your live site, your deployed environment variables, or your actual database policies — where many of the real problems live. An independent check that looks at the repo and the running app catches what the builder (human or AI) missed.
How do I check if my vibe-coded app is secure?+–
Scan it. SafeLaunch reads your repo and your live site and flags leaked secrets, open databases, client-side-only auth, risky dependencies, and missing live-site hardening in about 30 seconds — then hands you a prompt to paste back into your builder to fix each finding. It's $19, and apps that pass get listed in the verified directory.
Does the AI builder's own security scan cover this?+–
Some builders ship a scan, and it helps — but it mostly checks its own output, and often checks that a policy exists rather than whether it actually works (a database rule can be present and still let anyone read everything). Treat the built-in scan as a first pass, not a clean bill of health.