--- name: red-team description: Adversarial security audit by a senior security engineer + red team specialist persona. Scans across 7 pillars (auth, input handling, data security, API logic, multi-tenant isolation, infrastructure, dependencies) and hunts for chained exploits that combine multiple low-severity issues into critical ones. Outputs a structured report, Vulnerability Summary, Detailed Findings, Attack Chains, Secure Design Recommendations. Read-only, no fixes in same pass. Use before shipping new auth/billing/file-upload/multi-tenant features, after major refactors, or before going public. trigger: /red-team --- # /red-team Adversarial security audit. Senior security engineer + red team specialist persona. Treats your code as deployed in a hostile environment with motivated attackers. Looks for chained exploits, not just OWASP-checklist hits. This is a READ-ONLY pass. Output is a structured report of what's broken and how. No fixes, no refactors, that's a separate decision. The point is to surface the things you'd miss because you wrote the code yourself. ## Usage ``` /red-team # full repo (all layers) /red-team # specific dir or file /red-team auth # named subsystem (auth, billing, multi-tenancy, file-uploads, etc.) /red-team --diff # only what changed since main (pre-deploy) /red-team --diff # diff against a specific branch ``` ## When to use - **Before shipping a new auth/billing/file-upload/multi-tenant feature.** These are the four highest-value targets, auth bugs leak accounts, billing bugs leak money, file-upload bugs run code, multi-tenant bugs leak across orgs. - **After major refactors** that touched more than ~20 files. Refactors silently break invariants the original code held. - **Before going public/launching.** Vibe-coded apps ship with zero security review, speed and security are inversely correlated. If you've moved fast for two weeks, run this. - **When onboarding a new tenant to the Boxpress fleet** for the first time. Per-tenant DB isolation and per-tenant magic-link secrets need verification on the actual deployed instance, not just code review. ## When NOT to use - For trivial CRUD changes, overhead exceeds value. - As a first pass on a brand-new codebase you haven't read yet, you need the architecture in your head first or the report reads like noise. - As a substitute for `/ship-check`, that's about *deployability* (typecheck, build, migration safety, env vars). This is about *adversarial holes*. - For dependency-only audits, `npm audit` + `gh dependabot` cover known CVEs cheaper. ## What you must do when invoked ### Step 1, Establish the audit scope Read the user's argument: - No argument → audit the whole repo. Use Glob/Read to walk it. Spawn an Explore agent if codebase is >50 files. - A path → audit just that file/dir. - A subsystem name (`auth`, `billing`, `multi-tenancy`, `file-uploads`, `webhooks`, `cron`, `magic-link`) → grep for the relevant entry points and follow the call graph from there. - `--diff [branch]` → `git diff ...HEAD` and audit only what changed. If scope is the whole repo, START by spawning an Explore agent in parallel to map the architecture. You need: - Tech stack (framework, ORM, auth library) - Tenancy model (single-org, multi-tenant via org_id, dedicated-per-tenant) - Integrations (Stripe, Resend, R2, FluidPay, etc.) - Deployment target (Railway, Vercel, etc.) This context shapes the threat model. Skipping it produces generic findings. ### Step 2, Build the threat model FIRST, before scanning Don't dive into files. Spend 2-3 minutes thinking: - **Attacker profiles**, who's plausibly attacking this? - Anonymous web visitor - Authenticated low-privilege tenant user - Authenticated admin of one tenant trying to reach another tenant's data - Compromised tenant install (the magic-link rotation reason) - API consumer with a valid token - Insider (sales rep with stolen creds) - Supply-chain (compromised npm dep, compromised CI) - **Trust boundaries**, where does data cross from untrusted to trusted? - Public form → server action - Webhook receiver → DB write - User upload → R2 → served back as HTML - Cron service → internal endpoint - Magic-link admin → tenant install - **Crown jewels**, what's the worst case? - Customer PII / payment cards (cigar customers + age verification data) - Cross-tenant data exposure (one F&F sees another customer's orders) - Admin credential theft → fleet impersonation - Stored XSS in storefront → customer browser pwn - Webhook spoofing → tenant lifecycle manipulation Write this threat model into the report header. It scopes the audit and tells the reader why each finding matters. ### Step 3, Run the seven-pillar scan For each pillar, list specific things to look for. Use Read + Grep. Don't be exhaustive on examples; flag patterns the user should investigate. **1. Authentication & Authorization** - Session management, where are sessions issued, stored, expired? Are they invalidated on password change / magic-link rotation? - Role/permission gates on every protected route. Use `Grep -rn "requireOrgId\|requirePermission\|requireSession"` then look for routes that DON'T call any of these. - Privilege escalation: vertical (user → admin) and horizontal (org A → org B). The horizontal one is the multi-tenant killer. - Password reset / magic-link flows: token entropy, single-use enforcement, expiry, scope (which tenant can the token authorize against?). - Token leakage in URLs (referer header, server logs, browser history). **2. Input Handling** - Injection: SQL (Drizzle's `eq` is safe but raw `sql\`\`` template strings are not), NoSQL, OS command (any `child_process.exec` with user input), template injection (Handlebars/Nunjucks rendering with user data). - XSS: stored (user-submitted content rendered as HTML), reflected (URL params reflected to page), DOM-based (client-side dangerouslySetInnerHTML). - CSRF: any state-changing GET request, any form without origin check, any API endpoint without same-origin enforcement (NextAuth handles this for its own routes, custom server actions need verification). - File uploads: mime-type validation, size limits, sanitized filenames, storage outside the executable path, no double-extension bypass (.pdf.html), virus scanning if user-facing. - Open redirects: `?next=` or `?returnTo=` params not validated against an allow-list. **3. Data Security** - Sensitive data in logs (PII, tokens, full request bodies) - Encryption at rest where required (we have AES-256-GCM helpers, check they're actually used for secret columns: api keys, magic-link secrets, age-verification keys) - Hardcoded secrets, `Grep -rn "sk_live\|pk_live\|secret.*=.*[\"'][a-zA-Z0-9]{20,}"` to surface accidentally-committed values - localStorage / cookies storing tokens, should be httpOnly + Secure + SameSite=Strict - Logging frameworks scrubbing or NOT scrubbing sensitive fields **4. API & Backend Logic** - IDOR/BOLA: every `GET /api/things/:id` must verify the requester owns that thing. Check: does the query filter on `orgId` or `userId` AS WELL as the path param? - Mass assignment: `db.update(...).set(req.body)` is the smoking gun. Server actions accepting raw form data that flows directly to DB. - Rate limits on auth endpoints (login, magic-link issue, password reset, signup) - Business logic abuse: race conditions in inventory decrement, double-spending in coupon redemption, wholesale-tier abuse, drop allocation claim races - Webhook signature verification, Stripe, Resend, age-verification providers all sign their webhooks. Missing verification = anyone can spoof a state change. **5. Multi-Tenant Isolation (Boxpress-specific)** - Every Drizzle query in customer-facing routes filters by `orgId` (look for `eq(table.orgId, ...)`) or implicit tenancy via tenant DB connection - R2 keys prefixed with `${orgId}/` so tenant A can't enumerate tenant B's bucket listing - Cron jobs filter by tenant correctly when iterating - Email templates render tenant data ONLY for that tenant's recipients - Stripe webhook handler dispatches events to the right tenant via `stripeCustomerId` lookup **6. Infrastructure & Configuration** - CORS policy, `Access-Control-Allow-Origin: *` with credentials = bypass. Allow-list only. - CSP headers, set, restrictive, no `unsafe-inline` for scripts - HSTS, set with sensible max-age - Open ports / debug endpoints, no `/debug`, `/__nextjs_original-stack-frame`, `/admin` without auth - Environment variable leaks, `NEXT_PUBLIC_*` should NEVER contain secrets (these ship to the browser) - Cloud misconfig, R2 bucket public-list disabled, presigned URLs short-lived **7. Dependencies & Supply Chain** - Run `npm audit --json | jq '.vulnerabilities | to_entries | map(select(.value.severity == "high" or .value.severity == "critical"))'` if reasonable - Flag deps that have been transferred to suspicious maintainers (uncommon but devastating) - Flag any unsanitized `eval()`, `Function()`, `require()` - Flag postinstall scripts in deps you don't recognize ### Step 4, Hunt for chained exploits Standard checklists miss these. They're where vibe-coded apps get owned. Specifically look for: - **Two minor bugs that combine into a major one.** E.g. a self-XSS in admin combined with a CSRF in a settings change = stored admin XSS attacking other admins. - **State desyncs.** Webhook fires twice → tenant gets provisioned twice → second one inherits orphaned R2 bucket from first. - **Replay attacks.** Magic-link issued, captured, replayed after tenant rotation but before the JWT expiry. - **Timing attacks.** Login that returns "user not found" vs "wrong password" with different timing. - **Cache poisoning.** Edge cache keys that include user input, server response varied by user. - **Race conditions.** Two parallel requests to claim a drop allocation, both succeed because the check-then-write isn't atomic. - **Feature abuse.** A "share" feature that lets a user generate links to ANY internal URL. - **"Shouldn't be possible" behaviors.** Try to make the system do something the developer didn't anticipate. Example for Boxpress: can a sales rep order on behalf of a lounge whose org_id they don't actually belong to? ### Step 5, Output the report in this exact format ```markdown # /red-team, **Audited:** **Stack assumed:** **Tenancy model:** ## Threat Model **Attacker profiles considered:** **Trust boundaries:** **Crown jewels:** ## 1. Vulnerability Summary | Severity | Count | |----------|-------| | Critical | N | | High | N | | Medium | N | | Low | N | | Informational | N | ## 2. Detailed Findings ### [CRITICAL] **Affected:** `path/to/file.ts:123` **Description:** What's wrong. Cite the code. **Exploitation scenario:** Step-by-step what the attacker does. **Impact:** What they get. Be specific (data exfil, account takeover, RCE, etc.). **Recommended fix:** What to change. Don't write the patch, describe the shape of the fix. ### [HIGH] <Title> ... (continue for every finding, sorted by severity descending) ## 3. Attack Chains Chain 1: <Title> - Step 1: exploit finding #N - Step 2: combine with finding #M - Result: <impact bigger than either alone> (only include chains that actually work, don't pad with hypotheticals) ## 4. Secure Design Recommendations Architectural improvements that would prevent CLASSES of bugs, not just the ones found. - <Recommendation 1> - <Recommendation 2> - ... ## What I did NOT audit - <list anything you skipped, out of scope, didn't have access, etc.> ``` ### Step 6, Stop. Do not implement fixes. The skill is read-only by design. The user decides which findings to fix and in what order. Fixing in the same turn introduces bias (you'll downplay the severity of things you can't fix easily). Hand off the report and stop. If the user explicitly asks "fix the criticals" after seeing the report, that's a separate task, start fresh. ## Calibration for Jake's projects - **Boxpress fleet (boxpress, boxpress-platform, fathomfury):** multi-tenant isolation is the #1 risk. Every finding that crosses tenant boundaries is at minimum HIGH, often CRITICAL. - **F&F production (fathomfury):** age verification + PACT Act compliance bugs are CRITICAL, not just HIGH, they have legal exposure beyond data loss. - **EAA (Elite AI Advantage):** primarily customer marketing → Stripe billing flows. Watch for billing logic abuse + admin RBAC. - **FUEL:** content publishing pipeline. Watch for stored XSS in published content + cron-job race conditions. - **Anything Railway-deployed:** assume `DATABASE_URL` is the most valuable env var. Anything that could leak it (debug endpoints, error pages with stack traces, env-var enumeration) is HIGH. ## Mindset - "Do NOT assume the code is safe." - "Do NOT skip analysis due to missing context, infer risks where needed." - "Be exhaustive and PARANOID in your review." - "If unsure, flag it as a potential risk and explain why." - Vibe-coded apps ship with zero security review. Your job is to be the review they didn't have. - A finding you flag and the user dismisses is better than a finding you didn't flag and an attacker found. ## What to avoid - **Generic OWASP-list output.** "Look for SQL injection." Useless. Tell the user WHERE in their codebase you saw the smell. - **Over-quoting code.** Cite file:line, paraphrase the issue. Don't paste 30-line blocks. - **Padding the count.** Five real findings beat fifteen weak ones. Informational findings are fine but mark them as such, don't inflate severity. - **Recommending rewrites.** "Rewrite the entire auth system" is not actionable. Recommend the smallest change that closes the hole. - **Implementing fixes.** Read-only. The decision and the implementation are separate steps. - **Citing CVEs the dep is theoretically vulnerable to without checking if your code uses the affected function.** False positives erode trust in real findings.