The pre-ship audit for SaaS that takes money.
It finds the billing and data-isolation holes the generic scanners miss, on the Next.js + Supabase + Stripe stack.

---

You vibe-coded a SaaS. It charges with Stripe and stores user data in Supabase. Two questions you cannot answer right now:

1. Can a stranger read another user's data?
2. Can a stranger get your paid plan for free?

There are already good general security scanners for AI-built apps. They catch hardcoded secrets, XSS, CORS, SQL injection. Use them, they are worth it. But they barely touch the layer that actually loses you money and trust: the billing logic and the data-isolation logic of a real SaaS. A forgeable Stripe webhook. A paid plan unlocked from the success redirect URL. A guest-checkout race. A quota two requests slip past at once. A cancellation your code never handles, so the user keeps Pro for free forever.

saas-preflight is built for exactly that layer, by someone who shipped those bugs and fixed them the hard way.

It is defensive only. It finds weaknesses in your own code so you can close them. It writes no exploits and touches nothing you do not own.

See it in action

What it checks

Seven categories, plus a conditional one that runs only for multi-tenant apps. The ones in bold are where the generic scanners go quiet and this one goes deep.

1. AUTH: can a logged-in user reach data that is not theirs (IDOR, missing server-side checks, middleware that fails open, CSRF on cookie-authenticated route handlers, open redirects after auth)?
2. DATA: is the data boundary real (Supabase RLS off, queries with no owner filter, mass-assignment writes that set role or is_pro straight from the request body, public Storage buckets)?
3. BILLING: can an operation leave money charged but access not granted, or a Stripe webhook delivered twice grant twice, or a forged webhook unlock the paid plan for free?
4. INPUT: is untrusted input bounded before the DB, disk, an outbound fetch (SSRF), or the DOM?
5. CONFIG: secrets shipped to the browser, test vs live key mismatches, wide open CORS.
6. ABUSE: can an anonymous user drain your LLM or email bill, or slip past a freemium quota through a race?
7. TENANCY (multi-tenant only): can one tenant reach another tenant's data or session (a session cookie shared across subdomains, a forged tenant header, a custom domain still serving after a downgrade)? Runs only when the scanner detects multi-tenant signals, and is skipped for single-tenant apps.

Every finding carries a rule id (BILLING-WEBHOOK-001), a category, a confidence level, and a severity: P0 (ship blocker), P1 (fix this week), P2 (hardening), or P3 (hygiene), with a file, a line, and a concrete fix.

How it works

A single Node rule engine indexes the repo once, then runs every rule against that shared index. Each rule declares what it looks for and what guard would make it safe, so the engine can tell "this file matched a pattern" apart from "this file matched and the required guard is provably absent." That distinction is where the confidence level comes from: it is derived from the detection, never estimated.

Then the agent verifies each candidate by reading the actual code, because a static rule cannot prove exploitability. You get leads turned into confirmed findings, not a wall of false positives.

It runs wherever Node runs. No bash, no PowerShell, no npm install, no network call, and a rule that throws is contained instead of taking the run down.

Install

Claude Code:

git clone https://github.com/Comoco235/saas-preflight ~/.claude/skills/saas-preflight

Then tell Claude: "audit my SaaS before I ship" and point it at your repo. The skill triggers on its own when you talk about shipping, going to production, or whether your app is secure.

It uses the open SKILL.md standard, so it also works in Cursor, Codex CLI, and other agents that adopted it. Drop the folder into their skills directory.

Run the scanner directly

For a quick first look, without an agent:

node scripts/cli.js /path/to/your/repo

Node is the only requirement. The engine is vendored in this repo: no npm install, no dependencies, no network calls. Read-only.

Every finding carries a rule id, a severity, and a confidence level derived from how it was detected. CONFIRMED when a required guard is provably missing from the file, LIKELY when the context qualifies but nothing was proven, NEEDS_REVIEW for a plain textual match. No invented percentages.

Use it in CI

node scripts/cli.js . --ci

Exit codes: 0 nothing confirmed, 1 confirmed P2/P3, 2 confirmed P1, 3 confirmed P0, 4 usage error. Only CONFIRMED findings affect the exit code, so an unverified grep hit never breaks your pipeline.

# .github/workflows/preflight.yml
- run: node path/to/saas-preflight/scripts/cli.js . --ci

--format json emits the full result for your own tooling.

Why I built this

I ship SaaS solo, fast, with AI. I have personally hit every one of these seven failure modes in my own products and fixed them the hard way: a Stripe webhook that failed silently so nobody's subscription activated, a middleware that failed open under load, a guest-checkout race, quota counters two requests slipped past at once. This skill is that scar tissue, written down, so you do not have to learn it the way I did.

Built by sl2s. If it caught something real in your code, that is the whole point. Tell me what it found.

Changelog

Release notes live in CHANGELOG.md. The current release is v2.0.0, which replaced the dual shell scanner with a single Node rule engine. See the migration note there if you were calling scan.sh.

License

MIT. Use it, fork it, improve it.

Une version française de ce guide est disponible dans README.fr.md.