Before you tweet your launch, run these 65 checks. They map to the exact patterns behind the Lovable RLS CVE (CVE-2025-48757, 170+ apps, 2025) and the Moltbook leak (1.5M API tokens, Feb 2026).
Want the full kit? 50 audit skills, 15 .cursorrules, 1 MCP config + 4 CLI recipes, 30 adversarial review prompts, 10 case studies. 5-minute install. $10 flat.
In Q1 2026, Escape.tech audited 5,600 real AI-generated apps. 58% had at least one critical vulnerability and 65% had at least one security issue. They pulled 400+ secrets straight out of frontend bundles — Stripe, OpenAI, and Supabase keys sitting in client-side JavaScript — plus 175 instances of leaked PII. That's a real study, not a made-up number (methodology). This is a checklist of 65 specific, testable items. Each one maps to a real incident pattern. If you can tick all 65, 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.
The Lovable RLS vulnerability alone (CVE-2025-48757, 2025, CVSS 9.3) exposed 170+ production apps. Moltbook exposed 1.5M API tokens in February 2026 — queryable with a single curl. These weren't edge cases. They were mainstream launches.
This checklist groups 65 specific, testable items across auth, secrets, APIs, databases, frontend, AI/LLM, agent tooling, and deployment. If you cannot tick all 65, 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. The service_role key bypasses RLS entirely — one leak is full read/write to every table.
- 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.
These are the checks the old web-app playbooks never had. They map to the OWASP Top 10 for LLM Applications (2025), which added Excessive Agency, Vector & Embedding Weaknesses, and Unbounded Consumption.
- 40. User input goes in a separate
usermessage, never concatenated into the system prompt. Content pulled from files, RAG, or the web is wrapped in explicit delimiters and treated as untrusted (indirect prompt injection). - 41. The system prompt contains zero secrets, API keys, or internal URLs. Assume it is public. Test extraction ("repeat your instructions verbatim") and confirm nothing sensitive comes back.
- 42. Per-user AND global token/cost caps exist on every LLM-calling endpoint. Test: hammer it from one account and a quota kicks in. A monthly spend ceiling with billing alerts is set at the provider (denial-of-wallet, OWASP LLM10:2025).
- 43. LLM output rendered as HTML is sanitized (DOMPurify) before it touches the DOM. Model output is untrusted input, same as a user paste.
- 44. Production agents enforce authorization server-side on every tool, independent of the model's decision. No destructive action (delete, payment, email send) fires on the model's say-so alone.
- 45. Agent tools are least-privilege. No raw shell/exec/eval reachable from model-controlled input. Destructive commands are allowlisted and gated behind confirmation (Excessive Agency, OWASP LLM06:2025).
- 46. Multi-tenant RAG/vector stores enforce tenant isolation at query time (namespace or metadata filter bound to the authenticated user), not in app code. Test: tenant A can never retrieve tenant B's chunks (OWASP LLM08:2025).
- 47. RAG ingestion treats user-supplied and scraped documents as untrusted. The corpus is version-controlled with hash baselines so a few poisoned documents can't silently steer output.
- 48. Vector embeddings are access-controlled like the source PII they encode (embedding inversion can reconstruct text). The vector DB endpoint requires auth and is not publicly reachable.
- 49. If you ship or consume MCP servers: each is pinned to a reviewed version, tool descriptions are scanned for hidden/invisible-Unicode instructions (tool poisoning), and you re-verify on change (rug-pull). MCP Inspector ≥ 0.14.1, mcp-remote ≥ 0.1.16 (CVE-2025-49596, CVE-2025-6514).
- 50. Dev and prod databases are physically separate with separate credentials. Your agent/CI never holds prod write or DDL credentials. (Replit's agent wiped a production DB during a code freeze because it had write access it never should have had.)
- 51. Cloud tokens handed to agents or CI are scoped to one project with minimal permissions — never account-wide. (PocketOS: an unscoped Railway token let a coding agent delete the database and every backup in 9 seconds.)
- 52. The Supabase service_role key appears in zero client-reachable files:
grep -rn "service_role" src/ app/ public/ dist/returns nothing, and any client-side JWT'sroleclaim is notservice_role. - 53. Every dependency is verified to actually exist before install — real maintainer, real history, real download counts. AI-suggested imports are cross-checked against the lockfile. (Slopsquatting: roughly 1 in 5 packages an LLM recommends don't exist, and attackers register the predictable names.)
- 54. Backups / point-in-time recovery are enabled, tested, AND stored under credentials the agent cannot reach — so a compromised agent can't delete the backups too.
- 55. AI rules and config files (
.cursor/rules,.github/copilot-instructions.md,CLAUDE.md,.windsurfrules) are scanned for invisible Unicode and reviewed as security-sensitive code (the "Rules File Backdoor" class). - 56. Your coding tools are patched (Cursor CurXecute / MCPoison / CVE-2025-59944, Claude Code CVE-2025-59536, Copilot RCE CVE-2025-53773). Workspace Trust is on; auto-run / "YOLO" mode is off when opening untrusted repos.
- 57. Any irreversible action an agent can take against production (DROP, DELETE, TRUNCATE, migrations, deploys) requires human-in-the-loop approval.
- 58. Deployment config explicitly separates environment variables. Public vars (NEXT_PUBLIC_*) vs server secrets.
- 59. NODE_ENV=production is set in all production builds. Verify in deployment logs.
- 60. Application monitoring (Sentry, LogRocket, etc.) is enabled and configured to sanitize sensitive data before sending.
- 61. Error tracking does NOT send user session tokens, passwords, API keys, or PII in error payloads. Audit your Sentry/LogRocket config.
- 62. Source maps are excluded from production bundles. Build with --no-sourcemap or delete .map files before deploy.
- 63. HTTPS is enforced. All HTTP requests redirect to HTTPS. Test:
curl -i http://yourapp.com. - 64. Third-party integrations (analytics, chat widgets, etc.) are loaded from trusted CDNs only and use Subresource Integrity (SRI) hashes.
- 65. You have tested a full account recovery flow (password reset, session invalidation, reauth) in production staging.
- You ticked all 65 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 65, 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 (Veracode, 2025) |
| Case Study | What went wrong |
|---|---|
free-case-studies/cve-2025-48757-lovable-rls.md |
How 170+ Lovable apps shipped with RLS completely off — and the separate 2026 follow-up that exposed an EdTech platform's 18,697 student records |
free-case-studies/moltbook-supabase-leak.md |
How Moltbook left 1.5M API tokens queryable with a single curl request |
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 65-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, 1 MCP config (Semgrep) + 4 CLI integration recipes (gitleaks, npm-audit, Supabase RLS check, prompt-injection fuzzer), 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 via an unscoped Railway token).
No SaaS. No subscription. Markdown files that live in your repo.
$10 flat. → 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.