Before you tweet your launch — run these 47 checks. Same patterns behind the Lovable RLS CVE (170 apps, March 2025) and the Moltbook leak (1.5M API tokens, Feb 2026).
Want the full kit? 50 audit skills, 15 .cursorrules, 5 MCP configs, 30 adversarial review prompts, 10 case studies. 5-minute install. First 10 buyers $39, then $79.
91.5% of vibe-coded apps shipped in Q1 2026 had at least one critical vulnerability. That's from an Escape.tech audit of 5,600 real apps, not a made-up number. 1 in 4 had a Stripe or OpenAI key sitting in client-side JavaScript. This is a checklist of 47 specific, testable items. Each one maps to a real incident pattern. If you can tick all 47, ship. If you can't, fix what's blocking you.
Not a SaaS. Not a scanner. A flat list you run through before you push to prod.
You're 30 minutes from shipping. Stop. Run this first.
Recent audit of 5,600 AI-generated apps (Escape.tech, Q1 2026) shows 91.5% contain at least one critical vulnerability. The Lovable RLS vulnerability alone (CVE-2025-48757, March 2025) exposed 170+ production apps. Moltbook exposed 1.5M user tokens in February 2026. These weren't edge cases — they were mainstream launches.
This checklist groups 47 specific, testable items across auth, secrets, APIs, databases, frontend, and deployment. If you cannot tick all 47, do not ship.
- 1. Database Row-Level Security (RLS) is enabled on every table in your database.
- 2. RLS policies exist for every table and every role (anon, authenticated, service_role).
- 3. JWT tokens are validated server-side on every protected API route (never trust the frontend to validate auth).
- 4. Sessions rotate or invalidate after login (CSRF + session fixation protection).
- 5. Magic links (passwordless auth) are single-use, expire in <15 minutes, and are tied to user IP or device fingerprint.
- 6. You cannot update or delete users, orders, or sensitive records based on user-supplied IDs alone. Test: try updating another user's record by changing the ID in the request.
- 7. CSRF tokens are validated on state-changing requests (POST, PUT, DELETE) via double-submit cookie or SameSite=Strict.
- 8. Session cookies have HttpOnly, Secure, and SameSite=Strict flags set.
- 9. No secrets in NEXT_PUBLIC_* vars, Vue/React .env files, or hardcoded strings. Grep
NEXT_PUBLIC_and audit all vars. - 10. .env, .env.local, .env.*.local are in .gitignore and never committed. Check git history:
git log --all -p | grep -i "api_key\|secret". - 11. Supabase service_role key is ONLY in server-side .env (Node, Python, Go, etc.), never in frontend bundles or .env.local.
- 12. Stripe keys: public key in NEXT_PUBLIC_*, secret key server-only, webhook signing verified.
- 13. OpenAI, Anthropic, xAI API keys are never in frontend code; always proxied via your API.
- 14. No hardcoded API keys, database URLs, or credentials anywhere in source (including comments and unused code).
- 15. Secrets are rotated post-launch or if ever exposed in source history.
- 16. Rate limiting is active on /api/auth/*, /api/login, /api/register. Test: 100 requests/minute should return 429.
- 17. All user inputs to /api/* are validated with Zod, Yup, or similar before touching the database. No raw req.body passed to queries.
- 18. No mass assignment: user cannot set admin=true, role=admin, or other sensitive fields by POSTing them.
- 19. Webhook signatures are verified (compare HMAC-SHA256 signature header to expected value using a constant-time comparison).
- 20. CORS is not set to
*. Allowed origins are hardcoded and don't include localhost in production. - 21. SQL queries use parameterized statements only. No string concatenation of user input into SQL.
- 22. NoSQL queries (MongoDB, Firebase, etc.) do not concatenate user input into filters or selectors.
- 23. File uploads are validated (mime type + file size), stored outside web root, and renamed to prevent path traversal.
- 24. Redirects after login are whitelisted. Cannot redirect to an external domain via open redirect.
- 25. API does not make unvalidated external requests. Ensure URLs used in server-side requests come from your allowlist, not user input (SSRF prevention).
- 26. RLS is ENFORCED on all tables. The anon role cannot SELECT/INSERT/UPDATE/DELETE on any table without an explicit policy granting it.
- 27. Public anon role has zero default permissions. Policies grant only what's needed — read-only on public lists, never write.
- 28. Service-role key is used ONLY in server-side code. Verify:
grep -r "service_role" src/— should return zero results in frontend files. - 29. User data isolation: queries always filter by
auth.uid()orteam_id. No query returns all records across all users. - 30. Soft deletes (is_deleted flag) or archive tables prevent accidental data loss. Hard deletes are logged with actor + timestamp.
- 31. Database backups exist and are tested. You have verified you can restore from backup before this launch.
- 32. No dangerouslySetInnerHTML or innerHTML without DOMPurify sanitization. Audit every instance in the codebase.
- 33. All npm/pip/gem dependencies are scanned for known CVEs. Run
npm audit,pnpm audit, or Snyk before launch. - 34. Content Security Policy (CSP) is enabled in production (strict-dynamic, no unsafe-inline). Test in staging first.
- 35. No /api/debug, /admin/backdoor, or internal test endpoints are accessible in production. Grep for "debug", "mock", "test-only" routes.
- 36. X-Frame-Options: DENY is set. Verify the header is sent on every response (prevents clickjacking).
- 37. Error messages do not leak internal paths, stack traces, or database schema in production. Test 404, 500, and permission errors.
- 38. No prototype pollution: user-supplied objects are not merged into application objects without sanitization.
- 39. React: no inline event handlers with unsanitized user data. Use react-dompurify or equivalent for any user content rendered as HTML.
- 40. Deployment config explicitly separates environment variables — public vars (NEXT_PUBLIC_*) vs server secrets.
- 41. NODE_ENV=production is set in all production builds. Verify in deployment logs.
- 42. Application monitoring (Sentry, LogRocket, etc.) is enabled and configured to sanitize sensitive data before sending.
- 43. Error tracking does NOT send user session tokens, passwords, API keys, or PII in error payloads. Audit your Sentry/LogRocket config.
- 44. Source maps are excluded from production bundles. Build with --no-sourcemap or delete .map files before deploy.
- 45. HTTPS is enforced. All HTTP requests redirect to HTTPS. Test:
curl -i http://yourapp.com. - 46. Third-party integrations (analytics, chat widgets, etc.) are loaded from trusted CDNs only and use Subresource Integrity (SRI) hashes.
- 47. You have tested a full account recovery flow (password reset, session invalidation, reauth) in production staging.
- You ticked all 47 items.
- You tested 3–5 items manually (not just linting).
- You have a security contact email on your site (security@yourapp.com).
If you cannot confidently tick all 47, do not ship. Security debt from day one is expensive to pay down.
These skills are in 5-free-skills/ in this repo. Drop them into .claude/skills/ and run them with /skill <name> in Claude Code.
| Skill | What it does |
|---|---|
5-free-skills/audit-supabase-rls.md |
Runs SQL against your database and tells you exactly which tables are unprotected — the CVE-2025-48757 check |
5-free-skills/find-exposed-env-vars.md |
Greps your build output for secrets that NEXT_PUBLIC_ dragged into client JS |
5-free-skills/audit-prompt-injection-vectors.md |
Finds every place user input reaches an LLM call without a boundary |
5-free-skills/audit-rate-limiting.md |
Checks whether your auth routes actually reject after N attempts |
5-free-skills/find-xss-react.md |
Finds dangerouslySetInnerHTML and unsanitized output — 86% of AI-generated code fails this |
| Case Study | What went wrong |
|---|---|
free-case-studies/cve-2025-48757-lovable-rls.md |
How 170+ Lovable apps shipped with RLS completely off, including an EdTech platform with 18,697 student records |
free-case-studies/moltbook-supabase-leak.md |
How Moltbook leaked 1.5M API tokens for 8 months before anyone noticed |
Not a SaaS scanner. Not continuous monitoring. Nothing phones home.
These are static markdown files. You read them, you run the SQL queries and shell commands manually, you fix what they find. There's no dashboard. No alerts. No magic.
This also isn't a substitute for a professional pentest if you're handling health data, financial records, or anything regulated. The checklist covers the patterns that show up constantly in vibe-coded apps. It does not cover everything.
The 47-item checklist is free. The vault has 50 skills across 5 attack surfaces, including 12 that are specific to AI and LLM apps: prompt injection, MCP server security, agent permission escalation, vector DB isolation, RAG data leakage, system prompt extraction.
Also included: 15 Cursor rules, 5 MCP server configs, 4 checklists, 30 adversarial review prompts, and 10 case studies with full root-cause analysis (including PocketOS, where a Cursor + Claude Opus 4.6 agent deleted a production database and all backups in 9 seconds due to an unscoped Railway token).
No SaaS. No subscription. Markdown files that live in your repo.
$39 for the first 10 buyers, then $79. → rishabhvaai.gumroad.com/l/plddbd
claude-code cursor lovable v0 security mcp vibe-coding supabase next-js prompt-injection rls ai-security
If this checklist saved you from shipping something embarrassing, star the repo. Then send the link to whoever on your team is using Lovable or v0 without thinking about this stuff yet.