I scanned 5 real vibe-coded apps for security issues. The results surprised even me.
3 out of 5 were leaking their .env files and .git directories to the public internet — anyone could grab database credentials, API keys, and source code.
None of them had a Content Security Policy. None had clickjacking protection. One didn't even have a valid SSL certificate.
Here are the apps and what I found:
-
NewMom.help (Bolt + Supabase) — 🔴 4 critical, 2 high
.env exposed, .git exposed, CSP missing, no rate limiting -
Disko.is (Replit + React) — 🔴 4 critical
Same pattern: .env, .local, .git all public -
AltCloud.dev (Lovable + Bolt) — 🔴 2 critical
.git exposed, CSP missing, pycache exposed -
SleepingBaby.info (Cursor + Next.js) — 🟠 HIGH
Cleanest of the bunch: no .env leaks, just missing headers -
RemedyHunt.com (Bolt + Supabase) — 🔴 SSL invalid
Browser literally blocks the site
The fix? One header each. CSP, XFO, HSTS. A .gitignore entry. That's it.
I built a tool to automate catching these before shipping → https://vibesafe.store
Full report with all findings: [https://dev.to/amrakg93/i-scanned-5-real-vibe-coded-apps-with-a-security-scanner-heres-what-i-found-4a04]
Would love to hear — are you running any security checks before you deploy your vibe-coded apps?
What stood out to me wasn't the number of issues you found.
It was how quickly the findings seem to point toward a scanning problem.
Reading it, I found myself wondering whether the underlying issue is actually detection, or whether detection just happens to be where the consequences become visible.
Those can lead to pretty different products even if the reports end up looking similar.
That's a fair question. The deeper issue isn't just detection — it's that AI coding tools are optimized for 'does this compile?' not 'is this secure?' The detection is just where the abstraction leaks.
Take RLS in Supabase: Lovable ships it disabled by default. That's not a detection problem — that's a design decision baked into the tool. The scanner just reveals the consequence.
Same with hardcoded secrets: the AI doesn't know it shouldn't embed API keys in frontend code because the training data is full of examples that do exactly that.
So the real fix isn't better detection (though that helps). It's changing what the AI considers 'normal' — which is what the Shield file does. But first you have to know what's broken, which is where the scanner comes in.
That's exactly why I found your reply interesting.
I don't think the biggest strategic decision is the scanner or the Shield file.
It's the decision about what kind of engineering behavior your product is ultimately teaching.
I have a few thoughts on that which I don't think I can explain properly in a thread. If you're interested, what's the best email to reach you on?