I scanned 80 live AI-built apps for security holes. Here's what I found.

The method — and what 'passive' means

I pointed VibeShield at 80 live apps that were publicly listed as built with Lovable (sourced from public search results and a maker directory). For each one, the scanner read only the files any visitor's browser already downloads — the page and its JavaScript — and looked for two things: secret API keys that shouldn't be there, and backends (like Supabase) wired straight to the browser.

Three rules made this responsible research, not an attack. It was passive: I never queried anyone's database or tested anything — just read public files. It's anonymized: I report numbers, never names, and no individual app is identified. And it only covers apps their makers chose to publish. Three of the 83 I started with were unreachable, leaving 80 scanned.

Finding 1: zero exposed API keys (the good news)

Across all 80 apps, the scanner found no exposed secret keys — no Stripe sk_live, no OpenAI keys, no AWS keys sitting in the public JavaScript. None.

That's a real credit to the platform. The only keys present in the browser were the ones that are meant to be public (like the Supabase anon key). The dreaded 'my AI tool dumped my Stripe secret into the frontend' scenario simply didn't show up in this sample. If you've been told every AI-built app is leaking secret keys, this data pushes back on that — at least for apps built this way.

Finding 2: 36% wire a database straight to the browser

29 of the 80 apps (36%) ship a Supabase backend — its project URL and public anon key — directly to the client. The other 64% had no detectable open-backend exposure (often because they're simpler sites with no database at all).

Talking to Supabase from the browser is normal and by design. But it means one thing: the entire security of those apps' data rests on Row Level Security (RLS) being configured correctly on every table. There's no second lock.

Why that 36% is the real risk

The anon key is public — it's in everyone's browser. If Row Level Security is off on any table (or enabled with no real policy), that public key can read, and sometimes write, every row. There's no exploit required; it's just an HTTP request.

This isn't hypothetical. It's the exact pattern behind CVE-2025-48757, where researchers found 303 endpoints across 170 Lovable-built projects readable by unauthenticated requests using the public anon key — exposing emails, payment details, and personal data. Detecting that an app exposes Supabase is detecting that it's standing on that single setting.

What I deliberately did NOT do

I did not query a single one of those 29 databases to confirm whose RLS was actually off. I could have — the anon key is right there — and it would have made for a far more dramatic writeup. But querying databases you don't own, even with a public key, is testing other people's systems, and that's a line worth not crossing.

So this study can't tell you how many of the 36% are truly wide open. Only each app's owner can safely run that check on their own database. The honest finding is the exposure pattern, not a confirmed breach count — and I'd rather report the true, smaller number than an inflated one.

How to check your own app

If you built an app with Lovable, Bolt, v0, Cursor or Replit: paste its URL into VibeShield (free, passive) to see what your public files reveal. It takes about 30 seconds.

If your app uses Supabase, also open your Supabase dashboard's built-in Security Advisor and confirm Row Level Security is enabled — with real policies — on every table that holds user data. That one check is the difference between this study being an interesting stat and being your incident report.

Frequently asked questions

Did you name or expose any of the vulnerable apps?

No. The study is aggregate and anonymized — only numbers are reported, and no individual app is identified. Nothing was exploited.

Does 36% mean a third of these apps are hacked or wide open?

No. It means a third expose a Supabase database to the browser. Whether each one is actually readable depends on its Row Level Security configuration — which this passive study did not test. The real number that's open could be lower.

Is it a mistake to have the Supabase anon key in the browser?

No — the anon key is designed to be public. The risk is never the key itself; it's whether Row Level Security policies are correctly set up behind it.