Threat model

Threat Model Generation

Generate a structured threat model from a feature specification using STRIDE methodology.

Prerequisites

Before starting, locate:

1. The feature spec (.speckit/features/<feature>/spec.md or provided by user)
2. The project constitution (.speckit/constitution.md) for security constraints
3. The project stack (check package.json, CLAUDE.md)

Process

Step 1: Identify Assets and Trust Boundaries

Read the spec and identify:

• Data assets: What data does this feature handle? (PII, credentials, financial, content)
• Entry points: API routes, form inputs, webhooks, file uploads
• Trust boundaries: Client/server, authenticated/anonymous, admin/user, internal/external services
• Dependencies: Third-party services, databases, auth providers

Step 2: STRIDE Analysis

For each entry point, evaluate all 6 STRIDE categories:

Category	Question
Spoofing	Can an attacker impersonate a legitimate user or service?
Tampering	Can data be modified in transit or at rest without detection?
Repudiation	Can a user deny performing an action without accountability?
Information Disclosure	Can sensitive data leak through responses, logs, or errors?
Denial of Service	Can the feature be overwhelmed or made unavailable?
Elevation of Privilege	Can a user gain access beyond their authorization level?

Step 3: Risk Assessment

For each identified threat, assess:

• Likelihood: Low / Medium / High
• Impact: Low / Medium / High / Critical
• Risk Level: Likelihood x Impact matrix
• Existing mitigations: What the current stack already handles (e.g., Supabase RLS, Next.js CSRF)

Step 4: Mitigation Recommendations

For each Medium+ risk threat, propose:

• Specific code-level mitigation (Zod validation, RLS policy, rate limiting, etc.)
• Which story/task should implement it
• Whether it blocks the feature or can be addressed post-MVP

Step 5: Generate Report

Output to docs/security/<feature>-threat-model.md:

# Threat Model: <Feature Name>

**Date**: YYYY-MM-DD
**Spec**: .speckit/features/<feature>/spec.md
**Author**: Claude (automated)

## 1. Overview

Brief description of the feature and its security context.

## 2. Assets

| Asset | Type | Sensitivity |
|-------|------|------------|
| ... | PII / Financial / Content / System | High / Medium / Low |

## 3. Trust Boundaries

Diagram (text-based):

[Browser] --HTTPS--> [Next.js API] --SQL--> [Database] | | Trust Boundary 1 Trust Boundary 2

## 4. Threats (STRIDE)

### T-001: <Threat Name>
- **Category**: Spoofing / Tampering / ...
- **Entry Point**: POST /api/xxx
- **Description**: ...
- **Likelihood**: Medium
- **Impact**: High
- **Risk**: HIGH
- **Existing Mitigation**: Supabase RLS on table X
- **Recommended Mitigation**: Add Zod validation on input field Y
- **Priority**: Must-fix before MVP / Post-MVP acceptable

### T-002: ...

## 5. Risk Matrix

|          | Low Impact | Medium Impact | High Impact | Critical Impact |
|----------|-----------|--------------|-------------|----------------|
| **High** | Medium    | High         | Critical    | Critical       |
| **Medium** | Low     | Medium       | High        | Critical       |
| **Low**  | Info      | Low          | Medium      | High           |

## 6. Summary

- Total threats identified: N
- Critical: N | High: N | Medium: N | Low: N
- Must-fix before MVP: N
- Status: PASS / WARN / FAIL

Status Levels

• PASS: No Critical or High threats without mitigation
• WARN: High threats exist but have proposed mitigations
• FAIL: Critical threats without clear mitigation path

Common Patterns by Stack

Supabase + Stripe

• Check RLS policies cover all tables touched by the feature
• Verify webhook signature validation for Stripe events
• Ensure service_role key is never exposed client-side
• Check that Supabase auth tokens are validated server-side

Next.js (both starters)

• Server Actions: validate all inputs with Zod
• API routes: check authentication before processing
• Middleware: verify redirect targets are same-origin
• Environment variables: ensure no NEXT_PUBLIC_ prefix on secrets