stacks-security-audit

# /stacks-security-audit — Security Analysis You are performing a security analysis for a Stacks application. Be concrete — every finding must include a realistic exploit scenario. Vague warnings are worthless. ## Step 0: Run the scanner Run `buddy security:scan --show-ignored` first (see the `stacks-security` skill). It already covers vulnerable dependencies, committed secrets, dangerous calls, risky GitHub workflows and repository hygiene, so do not repeat those by hand: verify each finding it reports (read the code, confirm it is reachable) and spend your own effort on what a pattern scan cannot see: authorization gaps, business-logic abuse, trust boundaries and data exposure. Treat every `security-ignore` reason as a claim to check. ## Determine Scope 1. If the user specifies files or a feature, analyze that scope 2. Otherwise, analyze: API routes (`routes/`), auth flows (`@stacksjs/auth`), middleware, data handling, config/services.ts ## Step 1: Attack Surface Map ``` ## Attack Surface | Entry Point | Type | Auth Required? | Input Validation | |-------------|------|----------------|------------------| | [route/handler] | [HTTP/CLI/WebSocket] | [yes/no] | [description] | ``` For Stacks specifically, check: - API routes in `routes/api.ts` (136+ routes auto-generated) - CLI command handlers via `buddy` (command injection via user args) - WebSocket endpoints (`@stacksjs/realtime`) - Config file parsing - Dev server endpoints (`rpx`, `localtunnels` exposure) - Dashboard routes (auth middleware applied?) - File upload handling via `EnhancedRequest.file()` ## Step 2: OWASP Top 10 Evaluate each applicable category. **Only report findings with confidence ≥ 8/10.** For each finding: 1. **The vulnerability** — file:line reference 2. **Exploit scenario** — step-by-step 3. **Impact** — what attacker gains 4. **Confidence** — 1-10 5. **Fix** — concrete code change ``` ### [OWASP Category] 🔴 **[Finding]** (Confidence: [N]/10) **Location**: [file:line] **Vulnerability**: [what's wrong] **Exploit scenario**: 1. Attacker does [X] 2. System responds with [Y] 3. Attacker gains [Z] **Impact**: [specific impact] **Fix**: [concrete change] ``` ### Stacks-Specific Security Checks - **Auth token handling**: Check `@stacksjs/auth` for token validation, rotation (30d expiry, 7d rotation) - **Webhook URLs in `config/services.ts`**: Discord, Slack, Stripe keys — are they properly secured? - **ORM injection**: Check if user input flows unsanitized into query builder `.where()` calls - **Middleware gaps**: Are admin routes protected by `auth` middleware? Check `routes/api.ts` group middleware - **Rate limiting**: Is `throttle` middleware applied to auth endpoints? - **Passkey handling**: Check `@stacksjs/auth` passkey credential storage - **File uploads**: Check `EnhancedRequest.file()` for path traversal, size limits - **Maintenance mode bypass**: Check secret URL mechanism in Maintenance middleware ## Step 3: STRIDE Threat Model | Threat | Question | Finding | |--------|----------|---------| | **Spoofing** | Can someone impersonate a user/service? | | | **Tampering** | Can data be modified in transit/rest? | | | **Repudiation** | Can actions happen without traces? | | | **Information Disclosure** | Can unauthorized data be accessed? | | | **Denial of Service** | Can the system be made unavailable? | | | **Elevation of Privilege** | Can higher privileges be gained? | | ## Step 4: Dependency Audit 1. Read `package.json` for direct dependencies 2. Check for known vulnerabilities 3. Flag overly permissive version ranges 4. Check dependencies with filesystem/network/child_process access ## Output Format ``` # Security Analysis: [scope] ## Attack Surface [table] ## Critical Findings (Confidence ≥ 8/10) [findings sorted by severity] ## STRIDE Assessment [table] ## Dependency Audit [findings] ## Lower Confidence Observations [< 8/10 findings] ## Summary - Critical findings: [count] - Risk: [LOW / MEDIUM / HIGH / CRITICAL] ``` ## Rules - **Concrete exploits only.** "Doesn't validate input" is not a finding. Show the exact exploit. - **8/10 confidence threshold.** False positives erode trust. - **No theoretical threats.** If the code doesn't handle XML, skip XXE. - **Never suggest security-through-obscurity.** ## Downstream > **Security analysis complete.** Run `/stacks-review` to verify fixes against these findings.