stacks-security-audit

$npx mdskill add stacksjs/stacks/stacks-security-audit

Performs security audit on Stacks applications with exploit scenarios.

  • Identifies vulnerabilities in API routes, auth, middleware, and data handling.
  • Uses OWASP Top 10, STRIDE, attack surface mapping, and dependency audit.
  • Scans specified files or defaults to routes, auth, middleware, and config.
  • Outputs concrete exploit scenarios and actionable remediation steps.

SKILL.md

.github/skills/stacks-security-auditView on GitHub ↗
---
name: stacks-security-audit
description: Use when performing security analysis on a Stacks application — OWASP Top 10, STRIDE threat modeling, attack surface mapping, dependency audit. Requires concrete exploit scenarios. Invoke with /stacks-security-audit.
license: MIT
compatibility: Bun >= 1.3.0, TypeScript
allowed-tools: Read Edit Write Bash Grep Glob
---

# /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.

## 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.

More from stacksjs/stacks

SkillDescription
stacks-actionsUse when working with Stacks server actions — creating actions in app/Actions/, auto-generated API actions from the useApi model trait, the 80+ default framework actions (auth, dashboard, commerce, content, deployment, jobs), action request/response handling, or action registration. Covers @stacksjs/actions and storage/framework/defaults/actions/.
stacks-aiUse when integrating AI capabilities into a Stacks application — using Anthropic/OpenAI/Ollama/AWS Bedrock drivers, image generation (DALL-E), vision analysis, RAG/vector search, embeddings, MCP (Model Context Protocol) clients, text summarization, sentiment analysis, content classification, personalization, or the buddy AI assistant. Covers @stacksjs/ai and config/ai.ts.
stacks-aliasUse when working with path aliases in a Stacks project — import resolution, module aliasing, or debugging import paths. Covers @stacksjs/alias which defines 260+ path mappings for the entire framework.
stacks-analyticsUse when adding analytics to a Stacks application — configuring Fathom or self-hosted analytics, generating tracking scripts, privacy-friendly analytics setup, or the analytics configuration. Covers @stacksjs/analytics and config/analytics.ts.
stacks-apiUse when building, modifying, or debugging API endpoints in a Stacks application — defining routes, handling requests, API middleware, working with the API server, HTTP client (fetcher), API resources, or OpenAPI generation. Covers both @stacksjs/api utilities and the stacks-api server implementation.
stacks-arraysUse when working with array utilities in Stacks — statistical operations (average, median, mode, standard deviation, z-score, percentile, covariance), array manipulation (unique, flatten, partition, shuffle, sample, move), containment checks, or the Arr facade. Covers @stacksjs/arrays.
stacks-authUse when implementing authentication, authorization, passkeys, TOTP/2FA, RBAC, gates, policies, session auth, token management, email verification, password resets, or rate limiting in a Stacks application. Covers the @stacksjs/auth package, config/auth.ts, app/Gates.ts, and app/Middleware/.
stacks-auto-importsUse when working with the Stacks auto-import system — understanding how browser and server auto-imports work, configuring auto-imported functions/models/composables, the auto-import manifests, type generation, or how globals are injected. Covers the auto-import pipeline at storage/framework/auto-imports/.
stacks-brandkitUse when defining or exploring a brand identity for a Stacks project and you want premium brand-kit REFERENCE IMAGES first - logo directions, palettes, typography specimens, identity boards, and application/mockup decks. Generates IMAGES ONLY, never code. Trained for minimalist, cinematic, editorial, dark-tech, luxury, cultural, security, gaming, developer-tool, and consumer-app brand systems with intentional logo concepting, sparse type, strong symbolic meaning, and disciplined palettes a coding step can build against.
stacks-browseUse for headless browser QA on Stacks applications — navigation, screenshots, responsive testing, console/network monitoring, and accessibility snapshots. Dependency-free: drives a system browser over the Chrome DevTools Protocol using only Bun (no Playwright/Puppeteer). Invoke with /stacks-browse.