Vibe coding security statistics 2026: what scans found

AI app builders have made it possible to ship a working product in an afternoon. Several independent teams have now scanned thousands of those apps from the outside. This page collects their published findings in one place, quoted as published, with a link to each source, so you can check every number yourself.

A note on reading these numbers: they describe exposure found by scanning public apps, not confirmed attacks or breaches. They also use different samples and methods, so they should not be added together or compared as if they measured the same thing.

Key findings at a glance

Exposed secrets

Secrets in frontend code are the most direct kind of leak: a key copied from a public JavaScript file can be used immediately, and paid AI and payment APIs bill the owner.

• Escape (October 2025) analysed 5,600+ publicly available apps built on vibe-coding platforms and reported 400+ exposed secrets, alongside 175 instances of exposed personal data.
• VibeEval (August 2026) scanned 30,998 live vibe-coded apps and reported that 1,332, about 1 in 23, shipped a secret.

Why it happens and how to fix it: exposed API keys in your JavaScript.

Open Supabase databases

Supabase's public key is designed to be in the browser; Row Level Security decides what it can read. When RLS is off or too permissive, the public key reads the table.

• UpGuard (September 2026) reported finding 16,326 Supabase databases exposing readable tables to the public web, as covered by TechCrunch.
• VibeEval (August 2026) reported that 2,096 of 3,680 reachable Supabase-backed apps (57%) allowed unauthenticated table reads.
• Symbiotic Security (June 2026) scanned 1,072 Supabase-backed vibe-coded apps and found 98% had at least one security issue.

How to check your own project: is your Supabase database public?

Missing baseline defenses

• VibeEval (August 2026) reported that 99% of the 30,998 apps it scanned had at least one finding, mostly missing security headers.

Headers are missing defenses rather than exploits, but they are cheap to add: security headers for AI-built apps.

What these numbers do not tell you

• Not breaches. These studies report what was reachable from outside, not whether anyone misused it.
• Not directly comparable. Each team chose its own sample, checks and severity definitions.
• Not a verdict on any one platform. The pattern is common to AI-generated apps that go live without a security review, whichever tool built them.
• Not complete. An outside scan cannot see server-side logic behind a login, so real exposure may be higher or lower in any given app.

What to check in your own app first

The studies point at the same three places, in roughly this order of damage:

1. Secrets in the browser. Search your live JavaScript for sk_, sk-, service_role and sb_secret. Any hit is a key to rotate today, then move behind a server function. Which keys are safe, and which are not.
2. Tables the public key can read. Run the Supabase Security Advisor, enable Row Level Security on every table in public, and replace any using (true) policy on personal data with one scoped to auth.uid(). Step-by-step check.
3. Files that should never have been deployed. Request /.env and /.git/HEAD on your own domain. Neither should return the file. How to check and fix it.

After those, add the baseline security headers and work through the pre-launch checklist.

How to use this page

You are welcome to cite these figures. Please link to the original studies above, since they are the primary sources; this page is a summary that we update as new research is published.

To see where your own app stands, run a free, read-only PreflightX scan: it checks the same kinds of exposure these studies describe, on your app only.