12 security checks for your vibe-coded app — and the free tool for each

In March 2025, researchers scanned 1,645 apps on Lovable's showcase; 170 had data anyone could read (CVE-2025-48757).

The 12 checks

1. 01

   Row level security on every table

   Why: In Supabase, a table in the public schema without RLS can usually be read and changed by anyone who has your public key, and that key ships in your app. This is what the Lovable scan found.

   Check it: Supabase: Dashboard → Advisors → Security Advisor, or run it from a terminal with Supabase CLI v2.81.0 or later (after supabase link). Firebase: test mode "allows anyone to read and overwrite your data", so replace those rules before launch.

   supabase db advisors --linked --type security
2. 02

   Secret keys never in the browser

   Why: Publishable and anon keys are meant to be public. Secret and service_role keys bypass RLS, so they must stay on the server.

   Check it: In Next.js, anything prefixed NEXT_PUBLIC_ is shipped to the browser (in Vite, VITE_). Keep secret keys unprefixed and use them only in server code. /legal-check flags exposed keys.

3. 03

   No reading other users' data by changing an ID

   Why: Broken access control is #1 in the OWASP Top 10 (2025). It includes viewing or editing someone else's account by changing its ID (IDOR).

   Check it: Test it by hand: log in as user A, then change an id in a URL or API call to one that belongs to user B. You should get 403, not B's data.

4. 04

   .env not in your repo

   Why: Deleting a committed .env doesn't remove it: the key stays in your git history for anyone who can read the repo.

   Check it: gitleaks (MIT) scans your commit history (add --log-opts="--all" to include every branch). Add .env to .gitignore, and rotate any key it finds. Turn on GitHub push protection: free for public repos; private repos need GitHub Secret Protection, a paid add-on for GitHub Team or Enterprise organizations. Don't use npx gitleaks: the npm package with that name isn't the gitleaks project.

   brew install gitleaksgitleaks git -v
5. 05

   Rate limits on logins and AI endpoints

   Why: Without a limit, a bot can keep guessing passwords, and one script can run up your AI bill through your own endpoint.

   Check it: /legal-check checks login rate limits if you wrote your own password login (it skips hosted auth like Supabase Auth). For AI endpoints, add a per-user or per-IP limit at your host or edge, for example Vercel WAF rate limiting.

6. 06

   A hard spending cap on your AI API account

   Why: A leaked key or a runaway loop keeps spending until something stops it.

   Check it: OpenAI: Organization limits (or a project's Limits) → Spend → Edit spend limit, and turn on "Enforce a hard limit". Anthropic: Claude Console → Settings → Billing → Spend limits, or a workspace's Spend limits tab. Caps aren't instant: OpenAI says spend can slightly exceed the limit.

7. 07

   Server-side input validation

   Why: Checks in your form run in the browser. Anyone can skip them by calling your API directly.

   Check it: Validate every request body on the server with a schema, for example zod's safeParse, and reject what doesn't match.

   npm install zod
8. 08

   Stripe webhooks verify the signature

   Why: Without it, anyone can send your webhook URL a fake "payment succeeded" event.

   Check it: Call stripe.webhooks.constructEvent(rawBody, signature, endpointSecret) with the raw request body, the Stripe-Signature header and your endpoint's signing secret, and reject the request if it throws. Stripe's guide.

9. 09

   Admin and debug routes locked or removed

   Why: An /admin page or a test endpoint that's in your deployed app is public unless the server checks who's asking.

   Check it: /legal-check flags admin routes with no auth. Check the role on the server, not only in the UI, and delete debug routes before you ship.

10. 10

    Real packages, then an audit

    Why: AI can suggest packages that don't exist, and anyone can publish a package under a name it keeps inventing.

    Check it: Look up each new package on npmjs.com before you install it: the owner, the repo link, how widely it's used. Then run npm audit for known vulnerabilities.

    npm audit
11. 11

    Logs that catch attacks

    Why: If nothing is logged, you hear about an attack from your users or your bill.

    Check it: Check your host's logs: Vercel runtime logs, Supabase logs. Vercel's Hobby plan keeps runtime logs for only 1 hour, so look often, or send them to a log drain if you need history.

12. 12

    Backups you've restored

    Why: A backup you've never restored is a guess.

    Check it: Supabase keeps daily backups on Pro (7 days), Team (14) and Enterprise (up to 30), under Database → Backups. The Free plan has none, so export your data with the Supabase CLI. Then do one test restore.

Good to know

• This is not a professional security audit. It's a checklist of common gaps, and passing it doesn't mean your app is secure. If you handle payments or sensitive data, have a security professional review it.
• Lovable disputes CVE-2025-48757, saying protecting app data is each customer's responsibility. The 1,645 and 170 are from the researchers' statement, which scanned only homepages.