---
name: threat-model
description: Security - threat model
mode: subagent
tools: [bash, read]
workflows:
  - threat-model-workflow
---

# Security - Threat Model (Verbose)

Comprehensive threat modeling for systems, features, and architectures using STRIDE framework.

> ⚠️ **DISCLAIMER:** This threat model is generated by an AI assistant and is
> provided "as-is" without warranty of any kind. It is not a substitute for a
> professional security assessment. Threat models should be validated by qualified
> security professionals. You are solely responsible for verifying threats and
> implementing appropriate mitigations.

## STRIDE Framework

STRIDE is a systematic approach to identifying security threats:

1. **Spoofing** — Can an attacker impersonate another user or system?
2. **Tampering** — Can an attacker modify data in transit or at rest?
3. **Repudiation** — Can an attacker deny performing an action (lack of audit trail)?
4. **Information Disclosure** — Can an attacker access data they shouldn't?
5. **Denial of Service** — Can an attacker make the system unavailable?
6. **Elevation of Privilege** — Can an attacker gain unauthorized access or permissions?

## Threat Modeling Process

### 1. Identify Assets

What needs protection?
- User data (PII, credentials, financial data)
- API keys and secrets
- Business logic and intellectual property
- System availability

### 2. Map Data Flows

Create a data flow diagram showing:
- **External entities** (users, external APIs, third-party services)
- **Processes** (application code, background jobs)
- **Data stores** (databases, caches, file storage)
- **Data flows** (how data moves between components)

### 3. Identify Trust Boundaries

Where does trust change?
- User input (untrusted → trusted)
- External API responses (untrusted → trusted)
- Network boundaries (public → private)
- Privilege boundaries (user → admin)

### 4. Apply STRIDE to Each Component and Trust Boundary

For each component, ask STRIDE questions.

### 5. Prioritize Threats

**Likelihood:**
- HIGH: Easy to exploit, requires no special access
- MEDIUM: Requires some effort or specific conditions
- LOW: Difficult to exploit, requires insider access

**Impact:**
- HIGH: Data breach, system compromise, financial loss
- MEDIUM: Limited data exposure, degraded service
- LOW: Minor inconvenience, easily recovered

**Priority = Likelihood × Impact**

### 6. Propose Mitigations

For each threat, propose specific controls.

---

## Example: Payment API Threat Model

### System Overview

Users submit payment information via web form. API processes payment through Stripe. Payment details stored in database.

### Assets

1. Payment card data (PAN, CVV)
2. User PII (name, email, address)
3. API keys (Stripe secret key)
4. Transaction history

### Data Flow

```
[User Browser] → [Web Server] → [API Server] → [Stripe API]
                                     ↓
                               [Database]
```

### Trust Boundaries

1. User browser → Web server (untrusted → trusted)
2. Web server → API server (trusted → trusted)
3. API server → Stripe (trusted → external)
4. API server → Database (trusted → trusted)

---

## STRIDE Analysis

### Threat 1: Spoofing - User Impersonation

**Component:** Authentication endpoint  
**Scenario:** Attacker steals session token or JWT and impersonates legitimate user to make unauthorized payments.

**Impact:** HIGH - Attacker can make fraudulent payments using victim's account.

**Likelihood:** MEDIUM - Requires XSS or network interception to steal token.

**Priority:** HIGH

**Mitigations:**
- Use HttpOnly, Secure, SameSite cookies for session tokens
- Implement short token expiration (15 minutes)
- Require re-authentication for sensitive actions (e.g., changing payment method)
- Monitor for suspicious login patterns (IP changes, device changes)

---

### Threat 2: Tampering - Payment Amount Modification

**Component:** Payment submission form  
**Scenario:** Attacker modifies payment amount in browser before submitting (e.g., changes $100 to $1 using DevTools).

**Impact:** HIGH - Attacker pays less than required amount.

**Likelihood:** HIGH - Trivial to modify client-side values.

**Priority:** HIGH

**Mitigations:**
- **NEVER trust client-sent amounts**
- Server-side recalculation: `amount = cart.items.sum(item.price * item.quantity)`
- Sign payment requests with HMAC to detect tampering
- Log discrepancies between client-sent and server-calculated amounts

---

### Threat 3: Repudiation - Payment Denial

**Component:** Transaction logging  
**Scenario:** User claims they never made a payment, but no audit trail exists to prove otherwise.

**Impact:** MEDIUM - Chargeback disputes, lack of accountability.

**Likelihood:** MEDIUM - Users may legitimately dispute charges.

**Priority:** MEDIUM

**Mitigations:**
- Log all payment attempts with:
  - User ID, timestamp, IP address, device fingerprint
  - Payment amount, items purchased
  - Stripe transaction ID
- Retain logs for 7 years (compliance requirement)
- Implement log integrity (append-only, tamper-evident logging)

---

### Threat 4: Information Disclosure - PAN Exposure

**Component:** Database, logs, error messages  
**Scenario:** Attacker gains access to database or logs containing full credit card numbers (PAN).

**Impact:** CRITICAL - PCI-DSS violation, regulatory fines, loss of customer trust.

**Likelihood:** MEDIUM - Depends on database security.

**Priority:** CRITICAL

**Mitigations:**
- **NEVER store PAN in database** — use Stripe tokenization
- Store only last 4 digits for display: `card_last4 = "1234"`
- **NEVER log PAN** — redact in logs: `card=****1234`
- Encrypt database at rest (AES-256)
- Implement strict database access controls (least privilege)

---

### Threat 5: Denial of Service - API Rate Limiting

**Component:** Payment API endpoint  
**Scenario:** Attacker floods payment endpoint with requests, exhausting server resources or Stripe API rate limit.

**Impact:** MEDIUM - Legitimate users unable to complete payments.

**Likelihood:** HIGH - Easy to automate.

**Priority:** MEDIUM

**Mitigations:**
- Implement rate limiting: 10 payment attempts per user per hour
- Use CAPTCHA for repeated failures
- Implement exponential backoff for failed requests
- Monitor for abnormal request patterns
- Use CDN with DDoS protection (e.g., Cloudflare)

---

### Threat 6: Elevation of Privilege - Admin Panel Access

**Component:** Admin dashboard  
**Scenario:** Attacker exploits authorization flaw to access admin panel and view all payment transactions.

**Impact:** CRITICAL - Full access to all user payment data.

**Likelihood:** LOW - Requires authorization bug.

**Priority:** HIGH

**Mitigations:**
- Implement role-based access control (RBAC)
- Check authorization on EVERY admin endpoint: `if not current_user.is_admin: abort(403)`
- Use separate authentication for admin panel (e.g., MFA required)
- Log all admin actions
- Regularly audit admin access logs

---

## Threat Summary Template

```markdown
## Threat Model Summary

**System:** [System name]  
**Date:** [YYYY-MM-DD]  
**Reviewer:** [Name]

**Threats Identified:**
- CRITICAL: N
- HIGH: N
- MEDIUM: N
- LOW: N

**Top 3 Threats:**
1. [Threat name - Priority]
2. [Threat name - Priority]
3. [Threat name - Priority]

**Recommended Actions:**
- [ ] Implement mitigations for CRITICAL and HIGH threats
- [ ] Review threat model with security team
- [ ] Schedule penetration test after mitigations implemented
- [ ] Re-assess threat model quarterly
```

---

## Common Threats by Component Type

### Web Application
- Spoofing: Session hijacking, CSRF
- Tampering: Form manipulation, parameter tampering
- Information Disclosure: XSS, sensitive data in URLs
- DoS: Resource exhaustion, application-level DoS

### API
- Spoofing: API key theft, token replay
- Tampering: Request modification, MITM
- Information Disclosure: Verbose error messages, data leakage
- Elevation of Privilege: Broken access control, IDOR

### Database
- Spoofing: Credential theft
- Tampering: SQL injection, direct database access
- Repudiation: Missing audit logs
- Information Disclosure: Unencrypted data at rest

### Third-Party Integration
- Spoofing: API key compromise
- Tampering: MITM on API calls
- Information Disclosure: Over-sharing data with third party
- DoS: Third-party outage cascading to your system
