I Built a Tool That Audits Your Vibe-Coded App
This one's for the vibe coders and the founders who shipped an MVP last weekend and haven't thought about security since. I get it — you had an idea, you built it fast, it works. But if you used Supabase and an AI assistant to get there, there's a good chance you shipped a security hole without knowing it.
I kept seeing it over and over — open tables, leaked API keys sitting in JS bundles, no row-level security anywhere. So I built LeakScope to catch it automatically.
What it does
You paste a URL. That's it.
LeakScope crawls every JavaScript bundle your app ships to the browser, scanning for leaked credentials — Supabase keys, AWS secrets, Stripe keys, Firebase configs, anything. Then it registers a throwaway account, gets a real JWT, and starts probing your database the way an actual attacker would.
It tests every table it can find — SELECT, INSERT, UPDATE, DELETE — as both an anonymous visitor and a logged-in user. It checks for BOLA vulnerabilities. It scans for plaintext passwords. It tries alg:none JWT attacks. When it's done, it deletes the throwaway account and hands you a scored report with evidence and exact SQL to fix every issue it found.
Why it matters for founders
AI assistants are incredible at shipping features fast — but they consistently skip security configuration. The default Supabase table has no Row Level Security. VITE_ prefixed env vars are public by design. The service_role key bypasses every policy in your database.
You don't find out until someone else does.
LeakScope is the five-minute check between "I shipped it" and "I got breached."
We're in beta — and I need your feedback
LeakScope is early. I'm actively testing it, fixing edge cases, and figuring out what actually matters to the people using it. If you try it, I'd love to know what you think — what broke, what was confusing, what findings were actually useful.
The hard part right now isn't the tech. It's trust. A tool like this is inherently dual-use — the same scan that helps a founder secure their app could be pointed at someone else's. I've put rate limiting, CORS locks, and non-destructive-only checks in place, but I'm still thinking carefully about how to handle abuse at scale. If you have thoughts on that — ethical guardrails, access models, anything — I'm genuinely open to the conversation.
DM me on Telegram or drop a comment. I'm building this in the open and the feedback loop matters.
Check it out at LeakScope
Only use LeakScope on apps you own or have explicit permission to test.
