OWASP Threat Modeling
Threat modeling is the practice of systematically identifying what can go wrong in a system before an attacker finds it. It produces a prioritized list of security risks specific to your application — so you invest your limited security effort where it matters most. OWASP supports threat modeling through its Threat Modeling Cheat Sheet and the open-source Threat Dragon tool.
The Chess Analogy
Before making a move, a chess player looks several steps ahead: "If I move here, my opponent can take this piece, and then I lose that position." Threat modeling applies the same thinking to software design: "If we build this feature this way, an attacker can exploit this path, and the result is that kind of damage." Both approaches find the problem before it happens and give you time to change the plan.
Four Core Questions in Threat Modeling
1. What are we building?
Understand the system: components, data flows, trust boundaries
2. What can go wrong?
Identify threats to each component and data flow
3. What are we going to do about it?
Design mitigations for each identified threat
4. Did we do a good enough job?
Review the threat model and validate mitigations are in place
Step 1: Map the System with a Data Flow Diagram (DFD)
A DFD shows every component in the system, the data that flows between them, and the trust boundaries — the lines where different levels of trust exist.
DFD Symbols:
[Rectangle] External entity (user, partner, external service)
(Circle) Process (application logic, microservice)
===== Data store (database, cache, file system)
-------> Data flow (direction data travels)
- - - - - Trust boundary (where trust level changes)
Example DFD for a login feature:
[User Browser] ---username/password---> (Auth Service)
|
- - - - | - - - (trust boundary)
|
=Users DB=
Step 2: Identify Threats Using STRIDE
Apply the STRIDE model to each element in the DFD. For every process, data store, and data flow, ask which STRIDE threats apply.
Element: Auth Service process
S Spoofing Can an attacker impersonate a legitimate user?
YES --> Threat: Stolen credentials / session hijacking
T Tampering Can an attacker modify data in transit?
YES --> Threat: Modify login request in transit
R Repudiation Can a user deny an action they performed?
YES --> Threat: User denies initiating a password change
I Information Can sensitive data leak?
Disclosure YES --> Threat: Error messages reveal username existence
D Denial of Service Can the service be made unavailable?
YES --> Threat: Brute-force floods login endpoint
E Elevation of Can a low-privilege user gain higher access?
Privilege YES --> Threat: Normal user accesses admin panel
Step 3: Rate Each Threat with DREAD
DREAD scores help prioritize which threats to fix first by rating each on five dimensions from 1 (low) to 10 (high).
D Damage potential How bad is the damage if exploited? R Reproducibility How easily can the attack be repeated? E Exploitability How much skill does the attacker need? A Affected users How many users are impacted? D Discoverability How easy is it for an attacker to find this? Example: SQL Injection on login form D Damage: 9 (full database access) R Reproducibility: 10 (trivially repeatable) E Exploitability: 7 (basic knowledge needed) A Affected users: 10 (all users) D Discoverability: 8 (public login form, easy to find) Total score: 44 / 50 --> HIGH PRIORITY
Step 4: Define Mitigations
For each high-priority threat, define a specific technical control that addresses it. Link the mitigation to a requirement that can be verified in testing.
Threat: SQL Injection on login form Mitigation: Parameterized queries for all database calls Verification: SAST rule enabled; DAST SQL injection test must pass Threat: Brute-force on login endpoint Mitigation: Rate limit to 10 attempts per IP per 15 minutes; CAPTCHA after 5 failures Verification: Load test confirms rate limit triggers correctly
Step 5: Validate the Threat Model
After the mitigations are implemented, return to the threat model and confirm each control is in place. Update the model whenever the system changes — new features, new integrations, and architecture changes all introduce new threats.
OWASP Threat Dragon
Threat Dragon is a free, open-source threat modeling tool from OWASP. It provides a diagram editor for drawing DFDs, a library of STRIDE threats that auto-populate for each element, and report generation to document the threat model.
Threat Dragon workflow: 1. Draw system components and data flows in the diagram editor 2. Select each element -- STRIDE threats are suggested automatically 3. Mark threats as mitigated, out of scope, or needing action 4. Generate a threat model report for the development team 5. Import into project tracking (Jira, GitHub Issues) for remediation
When to Run a Threat Model
Event Action ────────────────────────────────────────────────────────── New application being designed Full threat model New feature with external data input Feature-level threat model New third-party integration added Integration threat model Significant architecture change Updated full threat model Annual security review Full model re-validation After a security incident Focused model on affected area
Lightweight Threat Modeling for Agile Teams
Full STRIDE/DREAD analysis on every sprint is impractical. Agile teams use a lightweight version: a 30–60 minute structured conversation at the start of each significant feature using four simple questions ("What are we building? What can go wrong? What do we do? Did we do enough?") with outputs captured as security user stories or acceptance criteria.
Quick Threat Modeling Checklist
[✓] Data flow diagram drawn for the system or feature [✓] Trust boundaries marked on the diagram [✓] STRIDE applied to each component and data flow [✓] Threats scored and prioritized [✓] Mitigation defined for each high-priority threat [✓] Mitigations tracked as requirements in the backlog [✓] Model updated when the system changes
Key Takeaway
Threat modeling finds security problems at the design stage — before code is written and before attackers find them in production. The STRIDE framework gives structure to the analysis, DREAD gives a priority order, and OWASP Threat Dragon gives a free tool to capture and track the results. Any team can start with a whiteboard and four questions.