Pre-Launch Security Kit: Offline Scanner, Supabase RLS Tests & 45-Check Checklist for Apps Built with Claude Code, Cursor & Codex

Your coding agent built the app. Before strangers sign up, check what it shipped by accident.

Coding agents are fast. They also put API keys behind NEXT_PUBLIC_, create Supabase tables without Row Level Security, write policies like using (true) and skip the Stripe webhook signature. Each of those is a one-line fix if you find it before launch. This kit finds them, explains each one and gives you the fix.

What's inside

• prelaunch_scan.py: an offline scanner with 28 rules.

• Provider keys in code, and secrets behind client-exposed env prefixes (NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_…).

• .env files tracked in git or still in git history.

• Supabase tables without RLS, RLS with no policies, using (true), policies that check login but not ownership, the service-role key in client code, public storage buckets.

• Firebase rules open to everyone.

• Wildcard CORS with credentials, write routes with no visible auth check, Stripe webhooks without signature verification, LLM endpoints with no rate limit, SQL built from strings.

• Unsanitized HTML, tokens in localStorage, hardcoded JWT secrets, debug mode, source maps, missing security headers.

• Secrets inside your built JS bundle.

• Every finding gives file:line, the value redacted, why it matters and how to fix it.

• Output as text, Markdown, JSON or SARIF. The exit code can fail your CI on high or critical findings.

• Inline and file-based ignores for false positives.

• It reads files only, never changes your repo, and sends nothing anywhere.

• gen_rls_tests.py: Supabase RLS tests generated from your migrations.

• 9 pgTAP checks per table: RLS is on; anon can't read or insert; user A can't read, update or delete user B's rows; user A can't create a row owned by someone else or hand their row to someone else; and user A can read their own, so a deny-all policy doesn't pass by accident.

• Run it with supabase test db.

• Tables it can't work out are marked TODO instead of guessed.

• Pre-launch checklist: 45 checks across secrets, database, auth, API, payments, AI endpoints, frontend and ops.

• Each check says how to verify it and which scanner rule covers it, if any.

• Comes as Markdown and as an Excel tracker with a status per check, a summary sheet and a “Launch ready?” cell.

• Agent prompts:

• A read-only audit prompt that has your coding agent run both tools, triage every finding and read the code for what static rules can't see, such as IDOR and missing ownership checks.

• 16 focused fix prompts.

• The same audit packaged as a SKILL.md skill.

• Fix templates:

• Supabase owner, team and storage policies, with pgTAP tests.

• Firebase Firestore and Storage rules.

• Security headers for Next.js, Vercel and Netlify/Cloudflare _headers.

• Verified Stripe webhook handlers for Next.js and Express.

• A GitHub Actions workflow with SARIF upload.

• A demo app to try first: a fictional vulnerable app with fake keys (25 findings) and its fixed version (0 findings).

• Docs: all 28 rules, what the kit does not catch, the sources it follows, how it was verified, and a 3-page Quick-Start PDF.

How it was checked

• The tools have 56 unit tests, which pass on Python 3.8 and 3.13.

• The generated RLS tests and the Supabase policy templates were run on PostgreSQL 17.5 with pgTAP and Supabase-style roles:

• The demo's broken policies fail 16 of 27 checks.

• The fixed policies pass all 27.

• The owner, team and storage templates pass their own tests.

• The scanner was also run against public open-source starter repos to cut false positives.

Who it's for: indie hackers and developers about to launch a web or mobile app built with Claude Code, Cursor, Codex or another coding agent (or by hand). It's most useful for Next.js / Vite / Expo frontends, Node or Python backends, and Supabase or Firebase.

Compatibility

• Python 3.8+, standard library only. No installs and no account. Plain files you can read and edit; it was built and tested on Linux.

• RLS test generation is for Supabase/Postgres SQL migrations. Running the tests needs the Supabase CLI and its local stack.

• The scanner has its best coverage for JavaScript/TypeScript and Python projects. Other languages get the secrets, env, git and CORS checks.

• Prompts and the skill work with any coding agent that can read files and run commands. The skill uses the open SKILL.md format read by Claude Code, Cursor and Codex.

Honest limits

• This is a static scan of your files plus a checklist. It is not a penetration test, audit or certification, and a clean scan doesn't mean your app is secure.

• It doesn't log in to your app or read your live database. Tables created only in the Supabase dashboard are invisible to it, so use Supabase's Security Advisor too.

• Detection is pattern-based:

• It will flag some safe code. For example, auth done in middleware looks like a route with no auth check.

• It can miss custom auth wrappers, business-logic bugs and IDOR.

• Deep secret-history scanning is narrower than dedicated tools like gitleaks.

• The RLS generator handles tables owned by a single user column. Team or membership data needs the hand-written template tests.

• The Firebase rule templates follow Firebase's documented syntax but were not run in the Firebase emulator. Test them before deploying.

• The scanner can tell you a key leaked. Only the provider can revoke it.

• For payments, health data or anything regulated, also get a professional review.

• The kit's files are in English.

License

• You can use it in any number of your own, your employer's or your clients' projects, commercial or not. You can commit the files to those repos and run them in CI.

• Don't resell or redistribute the kit itself.

Digital download (ZIP). Not affiliated with or endorsed by Anthropic, Anysphere (Cursor), OpenAI, Supabase, Google (Firebase), Stripe, Vercel, Netlify, or any tool named. Product names are used only to describe compatibility.