Vibe coding security: every risk, with real data
"Vibe coding" — building software by prompting an AI instead of writing it yourself — has put working apps in the hands of people who've never managed a server. That's genuinely powerful. It has also quietly created a wave of apps that leak their users' data, because AI builders optimise for "it works," not "it's safe." This is the complete picture of what goes wrong, backed by our own scans of hundreds of thousands of real apps, and how to make sure yours isn't one of them.
Check your vibe-coded app now
Paste your app's URL. Our free scan reads it from the outside and checks your database, secret keys, exposed files, transport and headers. No signup, nothing changed.
Only scan apps you own or have permission for.What is vibe coding security?
Vibe coding security is the practice of finding and fixing the security holes that appear in apps built with AI tools like Lovable, Bolt, Replit, v0 and Base44. It isn't a new class of vulnerability — it's the same classic mistakes (exposed databases, leaked keys, broken access control) showing up far more often, because the person shipping the app usually isn't a security engineer and the AI won't stop them. The risk isn't the tool. It's the gap between an app that runs and an app that's safe, and in vibe coding that gap is wide, silent and easy to miss.
What makes it different from traditional app security is the stack. Vibe-coded apps almost always lean on a hosted backend — Supabase, Firebase, Base44, Airtable, Bubble, Convex or Hasura — where a single toggle decides whether your data is private or public, and on third-party services (AI models, payments) whose keys are dangerously easy to paste in the wrong place. The whole risk surface is a handful of settings, and the AI leaves most of them at their least-secure default.
How common is it, really?
We don't have to guess. Our scanner runs the same passive, read-only checks against AI-built app backends at scale, and the numbers are stark.
Across 450,000+ vibe-coded app backends we scanned, roughly 13,600 were exposing data or secrets — most often a database readable without any login. The rate varies sharply by platform: on Base44 almost 1 in 3 flagged apps had a critical issue, on Firebase we found over 10,000 open databases, and even on Supabase — where most apps were locked down — hundreds were still leaking.
Based on publicly-reachable Supabase, Firebase and Base44 app backends we could enumerate and scan passively (read-only), as of September 2026. Aggregate figures only; no individual app is identified.Everything that can go wrong
Across every vibe-coded app we've scanned, the findings fall into six categories. Here they are, roughly in order of how much damage they do — and what our scanner looks for in each.
1. Databases anyone can read
The single biggest risk, and the most common. Every hosted backend has one setting that separates "only my app can read this" from "the whole internet can." AI builders routinely leave it open: they create tables and skip the access rules, because the app works either way. The result is a database that returns your users, their emails and their data to anyone who asks — no exploit, no login, just the public key that ships in your frontend.
It happens on every platform, each in its own way, and we check all of them:
Deep dives: Supabase (Row Level Security), Firebase (Security Rules) and Base44 (entity access).
2. Secret keys leaked into the frontend
The golden rule of keys is simple: secret keys belong on a server, never in the browser. But when an AI builder wires your app to an AI model or a payment provider, the fastest working version often bundles the secret key straight into the JavaScript your app ships to every visitor. Anyone can read it in their browser's developer tools and start spending your money or reaching your data.
We detect exposed keys from the major AI providers, plus payment and database admin secrets:
We tell real keys apart from harmless placeholders, so we only flag the ones that actually work. More detail: how to check for leaked API keys and the Supabase service_role key.
3. Sensitive files left public
An underrated one, and a favourite of the bots that scan the whole internet automatically. In the rush to ship, deploys often leave developer files sitting in the public web root, downloadable by anyone who knows the path. A single exposed file can hand over every secret in your app at once.
.env— the file that holds all your keys and database credentials, in plain text..git— your entire source code history, reconstructable from an exposed Git folder.- Database backups (
backup.sqland similar) — a full copy of your data, ready to download. .DS_Store— leaks your file and folder structure, a map for attackers.
4. Broken access control
Even with a login in place, the rules behind it can be wrong. AI-generated access logic is often subtly broken: a policy that lets any authenticated user read every row, an admin action reachable without the admin check, or permissions that let one user edit another's records. The door is locked, but the wrong keys open it. This is the class of bug behind several publicly reported vibe-coding breaches, where a working login gave a false sense of safety over a database that wasn't actually segmented per user.
5. Insecure transport (weak or missing HTTPS)
The padlock matters. We check whether your app forces HTTPS, whether its certificate is valid and current, and whether it still allows outdated, breakable encryption (old TLS versions, weak keys). If the connection can be downgraded or intercepted, everything your users type — passwords included — can be read on the way. It's less common than an open database, but it undermines everything else when it's wrong.
6. Missing security headers
Modern apps send the browser a set of protective rules — Content-Security-Policy, HSTS, X-Frame-Options and the rest — that block common tricks like cross-site scripting and clickjacking. Most vibe-coded apps ship without them. These are hardening rather than an open door, but they're a two-minute fix and close off a whole category of edge-case attacks.
Why vibe-coded apps leak by default
When you tell an AI builder to "add login" or "connect a database," it generates code that works in the preview immediately. The quickest working version routinely skips the parts that don't affect whether it runs but do decide whether it's safe: turning on Row Level Security, writing authenticated rules, keeping the secret key server-side, cleaning up deploy files. There's no error, no warning, and no obvious sign — the app looks finished. If you're not a developer, there's nothing to tell you that the same data you see in your dashboard is also visible to the entire internet. That silence is the whole problem, and it's why an external check matters: it looks at your app the way an attacker would, from the outside, with no assumptions.
The vibe coding security checklist
Before you launch or share a vibe-coded app, run through these six. They map directly onto the risks above and cover the vast majority of what we find.
- Lock down your database. Enable Row Level Security on Supabase, require auth in Firebase rules, and restrict entities on Base44, Bubble, Convex, Hasura or Airtable to logged-in users.
- Keep secret keys on the server. Move every AI, payment and admin key out of the frontend, and rotate anything that already leaked.
- Remove exposed files. Confirm
.env,.git, database backups and.DS_Storeare not downloadable from your live site. - Check permissions. Users should only reach their own data; no admin action should work without auth.
- Fix transport and headers. Force HTTPS with a valid certificate, and set Content-Security-Policy, HSTS and the other headers.
- Scan before you ship. Run an external check to confirm nothing is readable without a login, no secret is exposed, and no sensitive file is public.
Security by AI builder and backend
Each stack fails in a slightly different way. If you know what built your app, start here:
- Lovable and Supabase-backed apps — Row Level Security is the first thing to check.
- Base44 — the risk is entity access control, not leaked keys.
- Firebase apps — it's all in your Security Rules.
- Bolt.new, Replit and v0 apps — check the same fundamentals: open database, leaked keys, exposed files, weak auth.
- Airtable, Bubble, Convex and Hasura backends — each has its own access setting that's easy to leave open; our scan covers all of them.
Is your app one of the exposed ones?
Find out in about 10 seconds. Free, no signup, read-only — across all six risk categories.
Only scan apps you own or have permission for.The bottom line
Vibe coding is here to stay, and that's a good thing — but "it works" and "it's safe" are two different milestones, and the tools only get you to the first one. The fixes are almost always simple: turn on RLS, move a key to the server, delete a file, add a header. The hard part is just knowing which door was left open, across a stack you didn't hand-build. That's a two-minute check, and it's worth doing before real users — or a bot scraping the internet for open databases and exposed .env files — find the problem first.