Security Threat Model
Table of Contents
- Workflow
- STRIDE Framework
- Trust Boundary Mapping
- Common Patterns
- Guardrails
- Quick Reference
Workflow
Copy this checklist and track your progress:
Security Threat Model Progress:
- [ ] Step 1: Map system architecture and data flows
- [ ] Step 2: Identify trust boundaries
- [ ] Step 3: Classify data and compliance requirements
- [ ] Step 4: Apply STRIDE to identify threats
- [ ] Step 5: Define mitigations, monitoring, and prioritize risks
Step 1: Map system architecture and data flows
Document components, external services, users, data stores, and communication paths. See Common Patterns for architecture examples. For straightforward systems → Use resources/template.md.
Step 2: Identify trust boundaries
Mark where data crosses security domains (user → server, server → database, internal → third-party). See Trust Boundary Mapping for boundary types.
Step 3: Classify data and compliance requirements
Rate data sensitivity (public, internal, confidential, restricted), identify PII/PHI/PCI, document compliance obligations (GDPR, HIPAA, PCI DSS). See resources/template.md for classification tables.
Step 4: Apply STRIDE to identify threats
For each trust boundary and data flow, systematically check all six STRIDE threat categories. See STRIDE Framework for threat identification. For complex systems with multiple attack surfaces → Study resources/methodology.md for advanced attack tree analysis and DREAD scoring.
Step 5: Define mitigations, monitoring, and prioritize risks
Propose preventive/detective/corrective controls, establish monitoring and alerting, prioritize by risk score (likelihood × impact). Self-check using resources/evaluators/rubric_security_threat_model.json. Minimum standard: Average score ≥ 3.5.
STRIDE Framework
S - Spoofing Identity
- Threat: Attacker impersonates legitimate user or system
- Examples: Stolen credentials, session hijacking, caller ID spoofing, email spoofing
- Mitigations: Multi-factor authentication, certificate validation, cryptographic signatures, mutual TLS
T - Tampering with Data
- Threat: Unauthorized modification of data in transit or at rest
- Examples: Man-in-the-middle attacks, SQL injection, file modification, message replay
- Mitigations: HTTPS/TLS, input validation, parameterized queries, digital signatures, checksums, immutable storage
R - Repudiation
- Threat: User denies performing action, no proof of activity
- Examples: Deleted logs, unsigned transactions, missing audit trails
- Mitigations: Comprehensive audit logging, digital signatures on transactions, tamper-proof logs, third-party timestamping
I - Information Disclosure
- Threat: Exposure of sensitive information to unauthorized parties
- Examples: Database dumps, verbose error messages, unencrypted backups, API over-fetching
- Mitigations: Encryption at rest/in transit, access control, data minimization, secure deletion, redaction in logs
D - Denial of Service
- Threat: System becomes unavailable or degraded
- Examples: Resource exhaustion, distributed attacks, algorithmic complexity exploits, storage filling
- Mitigations: Rate limiting, auto-scaling, circuit breakers, input size limits, CDN/DDoS protection
E - Elevation of Privilege
- Threat: Attacker gains unauthorized access or permissions
- Examples: SQL injection to admin, IDOR to other user data, path traversal, privilege escalation bugs
- Mitigations: Principle of least privilege, input validation, authorization checks on every request, role-based access control
Trust Boundary Mapping
Trust boundary: Where data crosses security domains with different trust levels.
Common boundaries:
- User → Application: Untrusted input enters system (validate, sanitize, rate limit)
- Application → Database: Application credentials vs. user permissions (parameterized queries, connection pooling)
- Internal → External Service: Data leaves your control (encryption, audit logging, contract terms)
- Public → Private Network: Internet to internal systems (firewall, VPN, API gateway)
- Client-side → Server-side: JavaScript to backend (never trust client, re-validate server-side)
- Privileged → Unprivileged Code: Admin functions vs. user code (isolation, separate processes, security boundaries)
Boundary analysis questions:
- What data crosses this boundary? (classify sensitivity)
- Who/what is on each side? (authentication, authorization)
- What could go wrong at this crossing? (apply STRIDE)
- What controls protect this boundary? (authentication, encryption, validation, rate limiting)
Common Patterns
Pattern 1: Web Application with Database
- Boundaries: User ↔ Web Server ↔ Database
- Critical threats: SQLi (Tampering), XSS (Spoofing), CSRF (Spoofing), session hijacking (Spoofing), IDOR (Elevation of Privilege)
- Key mitigations: Parameterized queries, CSP headers, CSRF tokens, HttpOnly/Secure cookies, authorization checks
Pattern 2: API with Third-Party OAuth
- Boundaries: User ↔ Frontend ↔ API Server ↔ OAuth Provider ↔ Third-Party API
- Critical threats: Token theft (Spoofing), scope creep (Elevation of Privilege), authorization code interception, redirect URI manipulation
- Key mitigations: PKCE for public clients, state parameter validation, token rotation, minimal scopes, HTTPS only
Pattern 3: Microservices Architecture
- Boundaries: API Gateway ↔ Service A ↔ Service B ↔ Message Queue ↔ Database
- Critical threats: Service impersonation (Spoofing), lateral movement (Elevation of Privilege), message tampering (Tampering), service enumeration (Information Disclosure)
- Key mitigations: mTLS between services, service mesh, API authentication per service, network policies, least privilege IAM
Pattern 4: File Upload Service
- Boundaries: User ↔ Upload Handler ↔ Virus Scanner ↔ Object Storage
- Critical threats: Malware upload (Tampering), path traversal (Information Disclosure), file overwrite (Tampering), storage exhaustion (DoS)
- Key mitigations: File type validation (magic bytes not extension), size limits, virus scanning, unique file naming, separate storage domain
Pattern 5: Mobile App with Backend API
- Boundaries: Mobile App ↔ API Gateway ↔ Backend Services
- Critical threats: API key extraction (Information Disclosure), certificate pinning bypass (Tampering), local data theft (Information Disclosure), reverse engineering
- Key mitigations: Certificate pinning, ProGuard/R8 obfuscation, biometric auth, local encryption (Keychain/Keystore), root/jailbreak detection
Guardrails
Assume breach mindset:
- Don't ask "can attacker get in?" but "when attacker gets in, what damage can they do?"
- Defense in depth: Multiple overlapping controls, no single point of failure
- Least privilege: Minimal permissions by default, explicit grants only
Prioritize realistically:
- Focus on high-value assets (customer data, credentials, financial data) first
- Address compliance-critical threats (PCI, HIPAA) before nice-to-haves
- Balance security cost vs. risk (don't over-engineer low-risk systems)
Avoid security theater:
- Security theater: Controls that feel secure but don't meaningfully reduce risk (e.g., password complexity without rate limiting = still vulnerable to credential stuffing)
- Effective security: Address actual threat vectors with measurable risk reduction
Document assumptions:
- "Assumes database is not publicly accessible" (validate with network config)
- "Assumes TLS 1.2+ enforced" (verify in load balancer settings)
- "Assumes environment variables protected" (confirm secrets management)
Update threat model:
- Threat models decay (new features, new attack techniques, infrastructure changes)
- Review quarterly or when architecture changes significantly
- Incorporate lessons from incidents and security research
Quick Reference
Resources:
- Quick threat model: resources/template.md
- Advanced techniques: resources/methodology.md (attack trees, DREAD scoring, abuse cases)
- Quality rubric: resources/evaluators/rubric_security_threat_model.json
5-Step Process: Map Architecture → Identify Boundaries → Classify Data → Apply STRIDE → Mitigate & Monitor
STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
Trust Boundaries: User→App, App→DB, Internal→External, Public→Private, Client→Server, Privileged→Unprivileged
Mitigation Types: Preventive (block attacks), Detective (identify attacks), Corrective (respond to attacks)
Prioritization: High-value assets first, compliance-critical threats, realistic risk vs. cost balance
1---2name: security-threat-model3description: Systematically identifies vulnerabilities, threats, and mitigations for systems handling sensitive data using STRIDE methodology, trust boundary mapping, and defense-in-depth principles. Use when designing or reviewing systems with PII/PHI/financial/auth data, building security-sensitive features (auth, payments, file uploads, APIs), preparing for audits or compliance (PCI, HIPAA, SOC 2), investigating incidents, or integrating third-party services. Use when user mentions threat model, STRIDE, trust boundaries, attack surface, or security review.4---5
6# Security Threat Model
7
8## Table of Contents
91. [Workflow](#workflow)
102. [STRIDE Framework](#stride-framework)
113. [Trust Boundary Mapping](#trust-boundary-mapping)
124. [Common Patterns](#common-patterns)
135. [Guardrails](#guardrails)
146. [Quick Reference](#quick-reference)
15
16## Workflow
17
18Copy this checklist and track your progress:
19
20```
21Security Threat Model Progress:
22- [ ] Step 1: Map system architecture and data flows
23- [ ] Step 2: Identify trust boundaries
24- [ ] Step 3: Classify data and compliance requirements
25- [ ] Step 4: Apply STRIDE to identify threats
26- [ ] Step 5: Define mitigations, monitoring, and prioritize risks
27```
28
29**Step 1: Map system architecture and data flows**
30
31Document components, external services, users, data stores, and communication paths. See [Common Patterns](#common-patterns) for architecture examples. For straightforward systems → Use [resources/template.md](resources/template.md).
32
33**Step 2: Identify trust boundaries**
34
35Mark where data crosses security domains (user → server, server → database, internal → third-party). See [Trust Boundary Mapping](#trust-boundary-mapping) for boundary types.
36
37**Step 3: Classify data and compliance requirements**
38
39Rate data sensitivity (public, internal, confidential, restricted), identify PII/PHI/PCI, document compliance obligations (GDPR, HIPAA, PCI DSS). See [resources/template.md](resources/template.md) for classification tables.
40
41**Step 4: Apply STRIDE to identify threats**
42
43For each trust boundary and data flow, systematically check all six STRIDE threat categories. See [STRIDE Framework](#stride-framework) for threat identification. For complex systems with multiple attack surfaces → Study [resources/methodology.md](resources/methodology.md) for advanced attack tree analysis and DREAD scoring.
44
45**Step 5: Define mitigations, monitoring, and prioritize risks**
46
47Propose preventive/detective/corrective controls, establish monitoring and alerting, prioritize by risk score (likelihood × impact). Self-check using [resources/evaluators/rubric_security_threat_model.json](resources/evaluators/rubric_security_threat_model.json). Minimum standard: Average score ≥ 3.5.
48
49## STRIDE Framework
50
51**S - Spoofing Identity**
52- **Threat**: Attacker impersonates legitimate user or system
53- **Examples**: Stolen credentials, session hijacking, caller ID spoofing, email spoofing
54- **Mitigations**: Multi-factor authentication, certificate validation, cryptographic signatures, mutual TLS
55
56**T - Tampering with Data**
57- **Threat**: Unauthorized modification of data in transit or at rest
58- **Examples**: Man-in-the-middle attacks, SQL injection, file modification, message replay
59- **Mitigations**: HTTPS/TLS, input validation, parameterized queries, digital signatures, checksums, immutable storage
60
61**R - Repudiation**
62- **Threat**: User denies performing action, no proof of activity
63- **Examples**: Deleted logs, unsigned transactions, missing audit trails
64- **Mitigations**: Comprehensive audit logging, digital signatures on transactions, tamper-proof logs, third-party timestamping
65
66**I - Information Disclosure**
67- **Threat**: Exposure of sensitive information to unauthorized parties
68- **Examples**: Database dumps, verbose error messages, unencrypted backups, API over-fetching
69- **Mitigations**: Encryption at rest/in transit, access control, data minimization, secure deletion, redaction in logs
70
71**D - Denial of Service**
72- **Threat**: System becomes unavailable or degraded
73- **Examples**: Resource exhaustion, distributed attacks, algorithmic complexity exploits, storage filling
74- **Mitigations**: Rate limiting, auto-scaling, circuit breakers, input size limits, CDN/DDoS protection
75
76**E - Elevation of Privilege**
77- **Threat**: Attacker gains unauthorized access or permissions
78- **Examples**: SQL injection to admin, IDOR to other user data, path traversal, privilege escalation bugs
79- **Mitigations**: Principle of least privilege, input validation, authorization checks on every request, role-based access control
80
81## Trust Boundary Mapping
82
83**Trust boundary**: Where data crosses security domains with different trust levels.
84
85**Common boundaries:**
86- **User → Application**: Untrusted input enters system (validate, sanitize, rate limit)
87- **Application → Database**: Application credentials vs. user permissions (parameterized queries, connection pooling)
88- **Internal → External Service**: Data leaves your control (encryption, audit logging, contract terms)
89- **Public → Private Network**: Internet to internal systems (firewall, VPN, API gateway)
90- **Client-side → Server-side**: JavaScript to backend (never trust client, re-validate server-side)
91- **Privileged → Unprivileged Code**: Admin functions vs. user code (isolation, separate processes, security boundaries)
92
93**Boundary analysis questions:**
94- What data crosses this boundary? (classify sensitivity)
95- Who/what is on each side? (authentication, authorization)
96- What could go wrong at this crossing? (apply STRIDE)
97- What controls protect this boundary? (authentication, encryption, validation, rate limiting)
98
99## Common Patterns
100
101**Pattern 1: Web Application with Database**
102- **Boundaries**: User ↔ Web Server ↔ Database
103- **Critical threats**: SQLi (Tampering), XSS (Spoofing), CSRF (Spoofing), session hijacking (Spoofing), IDOR (Elevation of Privilege)
104- **Key mitigations**: Parameterized queries, CSP headers, CSRF tokens, HttpOnly/Secure cookies, authorization checks
105
106**Pattern 2: API with Third-Party OAuth**
107- **Boundaries**: User ↔ Frontend ↔ API Server ↔ OAuth Provider ↔ Third-Party API
108- **Critical threats**: Token theft (Spoofing), scope creep (Elevation of Privilege), authorization code interception, redirect URI manipulation
109- **Key mitigations**: PKCE for public clients, state parameter validation, token rotation, minimal scopes, HTTPS only
110
111**Pattern 3: Microservices Architecture**
112- **Boundaries**: API Gateway ↔ Service A ↔ Service B ↔ Message Queue ↔ Database
113- **Critical threats**: Service impersonation (Spoofing), lateral movement (Elevation of Privilege), message tampering (Tampering), service enumeration (Information Disclosure)
114- **Key mitigations**: mTLS between services, service mesh, API authentication per service, network policies, least privilege IAM
115
116**Pattern 4: File Upload Service**
117- **Boundaries**: User ↔ Upload Handler ↔ Virus Scanner ↔ Object Storage
118- **Critical threats**: Malware upload (Tampering), path traversal (Information Disclosure), file overwrite (Tampering), storage exhaustion (DoS)
119- **Key mitigations**: File type validation (magic bytes not extension), size limits, virus scanning, unique file naming, separate storage domain
120
121**Pattern 5: Mobile App with Backend API**
122- **Boundaries**: Mobile App ↔ API Gateway ↔ Backend Services
123- **Critical threats**: API key extraction (Information Disclosure), certificate pinning bypass (Tampering), local data theft (Information Disclosure), reverse engineering
124- **Key mitigations**: Certificate pinning, ProGuard/R8 obfuscation, biometric auth, local encryption (Keychain/Keystore), root/jailbreak detection
125
126## Guardrails
127
128**Assume breach mindset:**
129- Don't ask "can attacker get in?" but "when attacker gets in, what damage can they do?"
130- Defense in depth: Multiple overlapping controls, no single point of failure
131- Least privilege: Minimal permissions by default, explicit grants only
132
133**Prioritize realistically:**
134- Focus on high-value assets (customer data, credentials, financial data) first
135- Address compliance-critical threats (PCI, HIPAA) before nice-to-haves
136- Balance security cost vs. risk (don't over-engineer low-risk systems)
137
138**Avoid security theater:**
139- **Security theater**: Controls that feel secure but don't meaningfully reduce risk (e.g., password complexity without rate limiting = still vulnerable to credential stuffing)
140- **Effective security**: Address actual threat vectors with measurable risk reduction
141
142**Document assumptions:**
143- "Assumes database is not publicly accessible" (validate with network config)
144- "Assumes TLS 1.2+ enforced" (verify in load balancer settings)
145- "Assumes environment variables protected" (confirm secrets management)
146
147**Update threat model:**
148- Threat models decay (new features, new attack techniques, infrastructure changes)
149- Review quarterly or when architecture changes significantly
150- Incorporate lessons from incidents and security research
151
152## Quick Reference
153
154**Resources:**
155- **Quick threat model**: [resources/template.md](resources/template.md)
156- **Advanced techniques**: [resources/methodology.md](resources/methodology.md) (attack trees, DREAD scoring, abuse cases)
157- **Quality rubric**: [resources/evaluators/rubric_security_threat_model.json](resources/evaluators/rubric_security_threat_model.json)
158
159**5-Step Process**: Map Architecture → Identify Boundaries → Classify Data → Apply STRIDE → Mitigate & Monitor
160
161**STRIDE**: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
162
163**Trust Boundaries**: User→App, App→DB, Internal→External, Public→Private, Client→Server, Privileged→Unprivileged
164
165**Mitigation Types**: Preventive (block attacks), Detective (identify attacks), Corrective (respond to attacks)
166
167**Prioritization**: High-value assets first, compliance-critical threats, realistic risk vs. cost balance