BreachProbeONE URL, READ-ONLY
MENU
Scan free1 CRITICAL OPEN
33 issue types32 written fixes30 tables per scan2 throwaway accountsnothing written$19 report · $39 with 30 nightly re-scans

BREACHPROBE / CHECKLIST

Vibe coding security checklist

Nine checks between “it works on my screen” and “it’s safe for real users.” Built for apps shipped with Lovable, Bolt, v0 and Cursor, where the defaults are the problem.

SECTIONS
  1. No secret keys in the browser. Open dev tools, go to Sources, and search for your Supabase service_role or sb_secret_ key, Stripe sk_ key, or any provider key. If it’s there, it’s public. Rotate it first, then move it server-side.
  2. RLS enabled on every table. In Supabase, no user-data table should have row-level security off. Off means world-readable through the API.
  3. RLS policies actually isolate users. The check everyone skips: sign in as two users and confirm one can’t read the other’s rows. A policy can be on and still wrong.
  4. Email confirmation on. If signups are auto-confirmed, anyone can register accounts at scale and impersonate any email. Turn on Confirm email, or add a CAPTCHA.
  5. Authorization enforced server-side. Admin/role checks must live in RLS or an edge function, never a browser isAdmin flag anyone can flip.
  6. Session tokens in httpOnly cookies. Tokens in localStorage can be stolen by a single XSS. Prefer cookie storage.
  7. Security headers set. HSTS, a Content-Security-Policy, X-Frame-Options and nosniff — the hardening a vibe-code deploy skips by default.
  8. No IDOR via sequential ids. If records are fetched by /orders/123, changing the number must not return someone else’s order. RLS is what stops it.
  9. It actually works end to end. Signup, checkout and password reset should complete without errors. Broken flows lose users as surely as breaches do.

Why the defaults are the danger

AI builders optimise for “it works,” not “it’s locked down.” One published scan says it plainly: “We just finished scanning 1,003 vibe-coded apps across Lovable, Bolt, Replit, Vercel, Streamlit, Heroku, and others” — and of what it found, “RLS accounted for 183 of our 190 CRITs” (Lederer, dev.to, retrieved 7 August 2026). Those are the article’s body figures, and they are the ones quoted here: its headline advertises 1,764 apps and 453 critical findings, which the body does not restate. Take the ratio rather than either total — roughly nineteen in twenty critical findings were one row-level-security policy written wrong, not an exotic exploit. None of that is because founders are careless; it’s because the fast path leaves the doors open, and nothing tells you.

Run the whole checklist automatically

You can work through all nine by hand, or paste your URL into BreachProbe and have it run seven of them in seconds for free — including the hard one (RLS correctness) that requires becoming two users. The smoke test covers the last item: it drives signup, checkout and password reset in a real browser and shows you where they break.

Two of the nine have a guide of their own, because they are the two people get wrong most often: which API keys are actually safe to ship to the browser, and how to test that an RLS policy really isolates one user from another. If you want a tool for the list rather than a morning, the comparison of six Supabase security checkers sets out what each one tests and where each one stops.