Threat Modeling

Threat Modeling

Identify security threats BEFORE implementation using STRIDE methodology. This is proactive security — find threats at design time when mitigations are cheap, not at review time when they're expensive.

Use this when: the feature involves authentication, user input, external APIs, payment processing, PII, multi-tenant access, or any data flow that crosses trust boundaries.

Use super-agent-skills:security-and-hardening instead when: you're implementing and need reactive security checks (input validation, output encoding, etc.).

These skills complement each other: threat-modeling identifies WHAT to protect against (design time), security-and-hardening ensures the protection is correctly IMPLEMENTED (build time).

Announce at start: "I'm using threat-modeling to identify security threats before implementation."

When to Use

• Building authentication or authorization features
• Handling user input that flows to databases, APIs, or other systems
• Integrating with external APIs or third-party services
• Processing payments or sensitive financial data
• Storing or transmitting PII (personally identifiable information)
• Building multi-tenant features (data isolation between users/orgs)
• Adding webhooks, callbacks, or any external-facing endpoints

When NOT to use:

• Static content pages with no data flow
• Internal tools with no authentication
• Pure UI styling changes
• Documentation updates

STRIDE Framework

For each component or data flow in the feature, systematically check:

The Process

Step 1: Scope

Define what you're threat modeling:

• Which feature or component?
• What data does it handle?
• Who are the users (and potential attackers)?

Step 2: Diagram Data Flows

Map the system's data flows, identifying trust boundaries:

┌─────────────────────────────────────────────────┐
│ TRUST BOUNDARY: Public Internet                  │
│                                                  │
│  [User Browser] ──HTTP──→ [Load Balancer]        │
│                                                  │
├─────────────────────────────────────────────────┤
│ TRUST BOUNDARY: DMZ                              │
│                                                  │
│  [Load Balancer] ──→ [API Server]                │
│                                                  │
├─────────────────────────────────────────────────┤
│ TRUST BOUNDARY: Internal Network                 │
│                                                  │
│  [API Server] ──→ [Database]                     │
│  [API Server] ──→ [External Payment API]         │
│  [API Server] ──→ [Email Service]                │
│                                                  │
└─────────────────────────────────────────────────┘

Every arrow crossing a trust boundary is a potential attack surface.

Step 3: Apply STRIDE

For each component and each data flow crossing a trust boundary, check all 6 STRIDE categories:

### Component: API Server — POST /api/tasks

| STRIDE | Threat? | Detail | Severity |
|--------|---------|--------|----------|
| Spoofing | Yes | No auth check — anyone can create tasks | High |
| Tampering | Yes | Request body not validated — SQL injection risk | Critical |
| Repudiation | No | API logs all requests with user ID | - |
| Info Disclosure | Yes | Error messages expose stack trace | Medium |
| DoS | Yes | No rate limiting on endpoint | Medium |
| Elevation | Yes | No check that user belongs to the org | High |

Step 4: Prioritize

Rate each identified threat:

Step 5: Define Mitigations

For each High/Critical threat, define a specific countermeasure:

| Threat | Mitigation | Implementation |
|--------|-----------|----------------|
| No auth on POST /api/tasks | Add JWT validation middleware | Use existing authMiddleware from auth.ts |
| SQL injection in request body | Parameterized queries + Zod validation | Add TaskCreateSchema, apply at route level |
| Stack trace in errors | Sanitize error responses | Use existing ErrorHandler, disable stack in prod |
| No rate limiting | Add rate limiter middleware | Use express-rate-limit, 100 req/min per IP |
| Missing org membership check | Add org authorization check | Query org_members table before allowing action |

Step 6: Add to Spec

Append the threat model as a new section in the design spec:

## Threat Model

### Scope
[Feature being modeled]

### Threats Identified
[STRIDE table from Step 3]

### Mitigations
[Table from Step 5]

### Accepted Risks
[Low-priority threats that won't be mitigated, with justification]

These mitigations become acceptance criteria — the implementer must address them during build, and the reviewer must verify them during code review.

Output Format

The threat model document should contain:

1. Scope and data flow diagram
2. STRIDE analysis per component
3. Prioritized threat list
4. Mitigation plan for High/Critical threats
5. Accepted risks for Low/Medium threats

Anti-Rationalizations

Red Flags

• Building auth features without a threat model
• External-facing endpoints with no STRIDE analysis
• "Accepted risks" that are actually High severity (accepting what should be mitigated)
• Threat model that only covers Spoofing and Tampering (STRIDE has 6 categories — check all of them)
• No data flow diagram — you can't identify threats you can't see

Verification

After threat modeling:

• Data flow diagram exists showing trust boundaries
• STRIDE applied to every component crossing a trust boundary
• Every High/Critical threat has a specific mitigation
• Mitigations added as acceptance criteria in the spec
• Accepted risks are documented with justification
• security-and-hardening skill referenced for implementation phase