Are Vibe-Coded Apps Secure? We Scanned 61 to Find Out

Are vibe-coded apps secure? We scanned 61 live apps from Lovable, Bolt, v0, Replit, Cursor and Base44 — zero leaked a real key, but most flunk the basics.

Barret7 min read

You shipped an app with Lovable or Bolt or Cursor, it works, people are signing up — and the obvious question nags: are vibe-coded apps secure, and is yours? The headlines say every AI-built app is hemorrhaging secrets. So we stopped guessing and tested it.

We took 61 vibe-coded apps their own builders had publicly showcased — across Lovable, Bolt, v0, Replit, Cursor, and Base44 — and scanned each one, reading only what every visitor's browser already downloads. The result was not what the headlines predicted, and the most useful part is the line it drew between what's actually a problem and what only looks like one.

⚡ TL;DR

  • Zero of 61 apps were leaking a real secret key. Our first pass flagged 6 — every one a false positive (a Tailwind CSS class that resembles an API key). We checked the evidence, confirmed they were noise, and tightened our scanner.
  • The real, near-universal problem is boring: 53 of 61 apps are missing basic security headers.
  • 19 findings that look critical — Supabase anon keys, Firebase web config — are public by design, not leaks. Telling those apart is the entire job.
  • A scanner that can't tell a real key from a CSS class, or a public-by-design key from a secret, is worse than no scanner.

How we ran the scan (and what we didn't touch)

Transparency first, because the method is the credibility of any number like this.

Every app was something a builder had posted publicly — a showcase gallery, a launch thread, a forum. For each, the scan read only publicly-served artifacts: the HTML, the JavaScript bundles, and the response headers the site hands every visitor. The same things a browser or a search crawler already sees.

What we did not do: log in, submit a form, query a database, or send a single request that changes anything. Reading a site's public bundle is what a crawler does; poking at a database you don't own is not, and we don't cross that line without the owner's permission. Every result below is aggregate — no individual app is named.

So, are vibe-coded apps secure?

The short answer from 61 real apps: broadly under-hardened, but — in this sample — not actively leaking secrets.

Only 4 of the 61 came back with nothing flagged. The other 57 had at least one issue. But after we validated every finding, the serious category — exposed secret keys — came out at zero. The rest was missing security headers (very common) and public-by-design keys that look alarming and aren't.

One honest caveat: 61 apps scanned once is a snapshot, not a census. Other research finds real secrets at scale — Escape.tech scanned 5,600 vibe-coded apps and found 400+ exposed secrets — so "none in this batch" is a sample result, not a promise that secrets never leak. They do, and we cover the mechanics in an exposed OpenAI key is someone else's bill. The base rate is real and worth checking for — which is exactly why how you check matters.

The false alarm we caught — and what it teaches

Our first pass did flag 6 apps for exposed OpenAI keys: 29 "critical" findings. Here's what we did next, and it's the most important part of this post: we pulled the evidence before contacting anyone.

The matched strings were things like mask-image-linear-from-color and mask-image-radial-to-positionTailwind v4 utility classes. Their sk-image-… tail resembles an sk- key closely enough to trip a loose pattern, and their character mix cleared our entropy check. Four unrelated apps had byte-identical matches, because they all ship the same CSS framework. They were not keys. Nobody leaked anything.

So we fixed the matcher — a word boundary so a substring inside mask- can't match — and re-ran it. Zero.

That is the entire point of this exercise. A regex that matches sk-something is trivial. Knowing it's a CSS class and not a credential is the work. We would rather catch our own false positive than send six builders a fake emergency — which is precisely the check we ran before reaching out, and the answer was: don't.

What a naive scanner screams about (and shouldn't)

The Tailwind matches weren't the only false alarm waiting to happen. 19 findings across 17 apps were Supabase anon keys and Firebase web config sitting in the page source. A scanner that flags presence would call all 19 critical. Every one is harmless.

🐺 Not a real problem

Your Supabase anon key and Firebase web config are meant to live in the browser. They're identifiers — "talk to this project" — not passwords. The real risk is one level deeper: whether your Row Level Security (RLS) policies (the rules deciding who can read which rows) actually restrict data, or are missing or set to allow everyone. That gap is invisible from the outside and is what leaked 170 apps in CVE-2025-48757. The key isn't the emergency; the open rules are.

Add the Tailwind matches to the anon keys, and a careless scanner would have reported well over 40 "criticals" on this batch. The real number was zero. The distance between those two numbers is the distance between a tool you can trust and a wall of red you learn to tune out.

What's actually worth fixing: the boring stuff

The real, common finding is unglamorous. 53 of 61 apps were missing at least one standard security header — most often Content-Security-Policy (which limits what scripts a page can run), X-Frame-Options (which stops your site being embedded to trick users), and X-Content-Type-Options.

Keep these in proportion: a missing header is not "you've been hacked." It's a missing seatbelt — it doesn't cause the crash, it makes one worse. On their own they're hardening gaps, not live exploits. But they're baseline protection a real product is expected to have, and almost none of these had it. That tracks with Tenzai's December 2025 testing, which built apps across five AI tools and found zero of them set security headers by default. The category skips this, across the board.

The control group: stock templates were clean

To check our own discipline, 11 of the 61 were stock starter templates from v0 and Base44 — boilerplate, not real products. If a scanner is going to cry wolf, generic templates are where it shows. Those 11 came back with zero secrets and zero criticals — the same header gaps as everything else, and nothing falsely escalated.

How to check your own app

You can run the same checks on your own deployed app today:

  1. Search your bundle for secret keys. Open your live site, open dev tools, and search the JavaScript for sk-, sk_live, and similar — but confirm a hit is a real credential, not a class name or a publishable pk_ key. The validation is the part that matters.
  2. Check your headers. Your browser's network tab shows the response headers; look for Content-Security-Policy and X-Frame-Options.
  3. Confirm your access rules, not your keys. What actually leaks data is permissive RLS or Firebase rules — test that an anonymous request can't read what it shouldn't.

Want the same check on your own app?

Run a free, read-only scan of your live app — no install, results in under a minute.

Scan my app free →

FAQ

Are vibe-coded apps secure?

In our scan of 61, mostly under-hardened rather than catastrophic: only 4 were fully clean, most were missing baseline protections, and none were confirmed leaking a real secret key once every finding was validated. They can be secure — the AI ships code that works, not code that's hardened, so security is a step you add.

Did you find any apps actually leaking API keys?

No real ones in this batch. Our scanner's first pass flagged 6, but on inspection every match was a Tailwind CSS class that resembles a key, not a credential — so we corrected the scanner and reported zero. Worth stressing: 61 apps is a small sample, and other studies find real exposed secrets often, so this is not "it never happens."

My Supabase anon key shows up in the browser — is that a leak?

No. The anon key is public by design and belongs in the browser. Don't hide it. Spend the effort confirming your Row Level Security policies actually restrict access — that, not the key, is what protects your data.

The bottom line

Sixty-one apps, scanned the way any visitor's browser sees them: zero confirmed secret leaks, near-universal missing headers, and a pile of findings that look critical but are public by design. The real lesson isn't a scare statistic — it's that separating signal from noise is the entire job, and a scanner that can't or won't do it only trains you to ignore it. We hold ourselves to that: we caught our own false positive before it became six bad emails. An attacker can find your real gaps in minutes — find them first, on every deploy, and start with the complete guide to vibe-coding security.

Find your gaps before an attacker does.

Is My Site Hackable? scans your deployed app for the exact issues in this article — exposed keys, missing RLS, open buckets — and tells you what's real and what's a false alarm.

Run a free scan →