Security Audit

This is a defensive audit: the goal is to find weaknesses in your own app so you can fix them before launch, not to attack anyone. The highest-value findings for a Supabase + Stripe + Next.js booking app cluster in four places — leaked secrets, RLS gaps, broken object-level authorization (IDOR), and webhook trust. Those four are where real incidents on this stack actually happen, so weight the audit there.

Workflow

1. Scan for exposed secrets and risky config (fast, static, no dependencies):

   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/security/scan_secrets.py <project-dir>

It flags: Supabase service-role keys / JWT secrets in client-reachable code, Stripe secret keys (sk_live/sk_test) outside server-only files, generic API keys and private keys, .env files that look committed, and use of the NEXT_PUBLIC_ prefix on values that must stay server-side (this prefix ships the value to the browser — a service-role key behind it is a full database breach).

1. Review the four high-risk areas by hand using references/threat-model.md,

which walks each one with what to grep for and what "good" looks like:

• Secrets & env — confirm service-role key is server-only; client uses anon key.
• Supabase RLS — every table with user data has RLS enabled and policies

that scope rows to the owner. RLS disabled = the anon key reads everything.

• Authorization / IDOR — route handlers check that the caller owns the

resource (/api/bookings/[id] must verify the booking belongs to the user), not just that they're logged in.

• Stripe webhooks — handler verifies the signature with the webhook secret

and dedupes on event id; amounts are taken from Stripe, never trusted from the client.

1. Check dependencies for known vulnerabilities:

   npm audit --omit=dev || true

Report high/critical advisories with the upgrade path; don't drown the user in transitive low-severity noise.

1. Report by severity. Use the structure below. For each finding give the

concrete location, why it's exploitable (the scenario), and the fix. Be precise about severity — a sk_live key in client code is Critical; a missing security header is Low.

Report structure

ALWAYS use this template so findings are scannable and actionable:

# Security Audit — <app>
## Summary
<one-paragraph posture: what's solid, what's urgent>
## Critical
- [finding] — location · scenario · fix
## High
## Medium
## Low / Hardening
## Verified-safe
<things checked that were fine — so the user knows coverage>

Scope and ethics

This skill only inspects code and configuration the user owns and runs read-only checks. It does not exploit, exfiltrate, or attack live systems, and it will not produce attack tooling. If a check needs to hit a running endpoint (e.g. probing an IDOR), do it against the user's own dev/staging environment with their go-ahead.

When to hand off to the agent

For a full standing audit, delegate to the security-auditor agent — it runs the scanners, works through the threat model against the codebase, checks dependencies, and returns the severity-ranked report.