What the data actually says about vibe-coded app security
Scans of thousands of apps built with Lovable, Bolt and v0 reveal exposed secrets and open databases. What the 2026 data shows — and how to check your own.
If you shipped an app with Lovable, Bolt, v0 or Cursor, here’s an uncomfortable question almost nobody asked you: who can read your database right now? The 2026 data says that, in most cases, the answer is “anyone with your URL.” Here’s what large-scale scans actually found — without the fear-marketing — and how to check your own app.
TL;DR
- In a scan of 1,072 vibe-coded apps on Supabase, 98% had at least one security flaw and 16% had a critical one (Symbiotic Security, 2026).
- A separate study of 5,600 apps found 2,000+ vulnerabilities, 400+ exposed secrets and 175 cases of personal data — including medical records and IBANs (Escape.tech, 2025).
- The #1 pattern: Supabase databases with no Row Level Security, formalized in Lovable as CVE-2025-48757 (CVSS 9.3).
- It’s not your fault: AI optimizes for “it works,” not “it’s secure.” But it is your job to check before you launch.
How secure are vibe-coded apps?
AI-generated apps fail at security by default: the largest public scans find at least one issue in the overwhelming majority of them. This isn’t an edge case or a vendor scare — it’s a pattern measured across thousands of real apps, with the same root cause again and again: configuration the model never applied because nobody asked for it.
“Vibe-coded” means describing what you want and letting AI build it. The problem is that security isn’t something you see in the demo: the app works, looks right, and passes tests while the database sits wide open behind it.
What large-scale scans found
Three independent sources measured this in 2025–2026, all in passive mode (nothing exploited, no data touched) and all publishing only aggregated results:
| Source | Sample | Key finding |
|---|---|---|
| Symbiotic Security (2026) | 1,072 Supabase apps | 98% had ≥1 flaw · 16% critical |
| Escape.tech (2025) | 5,600 apps | 2,000+ vulns · 400+ secrets · 175 PII |
| CVE-2025-48757 (NVD) | — | Insufficient RLS in Lovable, CVSS 9.3 |
Both studies stress their numbers are a floor, not a ceiling: passive mode understates the problem because it never tries to exploit anything. And both point to the same culprit.
What exactly leaks
What gets exposed almost always falls into three concrete buckets, all detectable from the browser with no special tools:
- Secrets in the public JavaScript. Stripe, OpenAI, Google Maps or Supabase
service_rolekeys end up inside the bundle your browser downloads. Anyone opens DevTools and copies them. - Databases with no Row Level Security. With Supabase’s anon key (public by design) and RLS off, a visitor can read — or write — entire tables. This is the heart of CVE-2025-48757.
- Personal data. Emails, phone numbers, addresses, payment status. Escape.tech even reported medical records and IBANs among the 175 PII cases it found.
Why it happens (and why it’s not your fault)
When you ask a model to “build a dashboard with Supabase,” it prioritizes making it work. RLS, HTTP headers, restrictive CORS and server-side validation are details that don’t reach the output unless you ask for them explicitly — the happy path wins. Vibe-coding flows have no security step either: idea → app → deploy, with no gate in between.
The good news: these are missing configuration, not deep bugs. They’re quick to fix once you know they’re there.
How to check your own app (free, in minutes)
You don’t need to be an expert. Three manual checks cover most of the risk:
- Secrets: open your site, F12 → Sources, search for
sk_,service_role,apiKey. If a secret key shows up, it’s exposed. - Supabase RLS: take your Supabase URL and the anon key from the bundle and request
/(rest/v1/)<table>?limit=1with no session. If it returns real rows, RLS is open. - Leaked files: try
your-site.com/.git/HEADandyour-site.com/.env. If they return content, they shouldn’t.
For stack-specific steps, see our Lovable security guide and Supabase security guide, which walk through exactly what to check on each platform.
Prefer a tool to do it? VibeAuditt runs 12 passive checks against your URL in about 30 seconds — without touching your database, no payloads — and tells you what to fix. It’s passive reconnaissance, not a pentest.
What these studies don’t tell you
Here’s the honest part most articles on this topic skip:
- “1 in 5 apps is vulnerable” is misleading. Wiz’s figure refers to organizations adopting these platforms, not the share of apps that are vulnerable, and it discloses no sample size. Don’t use it as a prevalence rate.
- All three studies come from security vendors with a product to sell. Their numbers are useful and consistent, but they’re vendor blogs, not peer-reviewed research. The most neutral anchor is the NVD record for the CVE.
- CVE-2025-48757 is marked “disputed” by the vendor (its position: each customer owns their app’s data). It’s credited to researcher Matan Getz. It’s still CVSS 9.3.
- Be wary of round numbers with no source like “89% missing RLS” or “67% critical”: they circulate widely with no methodology behind them.
A topic being a fear-marketing commodity doesn’t make it false — but it does mean you have to separate the data from the headline. The problem is real; half the figures you’ll see are not.
Bottom line
Vibe-coded app security isn’t invented panic or a guarantee — it’s a measurable risk, with one recurring root cause (missing RLS + secrets in the client) and an accessible fix. If you shipped something with AI, spend five minutes on the three checks above — or let a passive scanner run them — before a curious stranger does it first.
// preguntas frecuentes
Preguntas frecuentes
Is my Lovable or Bolt app secure?
Not by default. In a scan of 1,072 Supabase-backed apps, Symbiotic Security found 98% had at least one flaw and 16% had a critical one. The usual culprits: keys exposed in the JavaScript bundle and databases without Row Level Security. Check it before you launch.
What data leaks from vibe-coded apps?
Three classes: secrets (Stripe, OpenAI or Supabase keys in the public JS bundle), databases without RLS readable with the anon key, and personal data. Escape.tech reported 400+ exposed secrets and 175 PII cases — including medical records and IBANs — across 5,600 apps.
Why does AI generate insecure code?
Models optimize for code that works, not code that's secure. Patterns like RLS, CSP or server-side validation don't show up unless you ask for them explicitly. It's not a capability gap — it's priorities: the happy path dominates the output.
How do I check if my app leaks data?
Open your site with DevTools (F12) and search the JS bundle for keys; query your Supabase URL with the anon key while logged out; check whether /.git or /.env respond. Or run a passive scanner that does the checks for you in seconds, without touching your database.
Is it legal to scan a web app's security?
Passive GET requests to public pages — what any browser does — generally aren't unauthorized-access crimes under US law. But only scan apps you own or are authorized to test, and never publish someone else's secrets or name vulnerable sites.
// escanear ahora
Audita tu SaaS gratis
Recibí un reporte de seguridad en menos de un minuto. Detectamos claves expuestas, RLS deshabilitado, headers de seguridad ausentes y más. Sin tarjeta, sin instalación.
10 auditorías gratis al mes · reportes detallados desde 9 USD