A STRIDE threat model starts from a data flow diagram (DFD) of the system, draws trust boundaries where privilege changes, and then walks every element asking which of six threats applies: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. This sample models a small online shop and tags each element with numbered threats and mitigations. DFDs are not UML: UML covers software structure and behaviour; DFDs and the other diagrams in this section are the standard notations used alongside it.
1. The Diagram
Walk through it in this order:
The Customer is an external entity on the Internet side of TB1. Anything that crosses TB1 is untrusted input.
1.0 Web App receives HTTPS requests. It sits in the DMZ and is the most exposed process, so it collects three threats (T3, T6 and the flow threat T2).
Inside TB2 the web app calls 2.0 Auth Service to check the session and 3.0 Order Service to place orders.
Each service owns one data store: D1 Users DB and D2 Orders DB. No process reads another service's store directly.
The order service charges the card through the external Payment provider over mutual TLS. That flow crosses TB2 outward, so it is another boundary to analyse.
The table at the bottom records each threat with the element it applies to and the agreed mitigation. Every row becomes a ticket or a test.
2. How to Read It
The notation is Gane-Sarson/DeMarco-style DFD as used by the Microsoft Threat Modeling Tool and OWASP Threat Dragon: rectangles are things you do not control, circles are your code, open rectangles hold data at rest, and arrows carry named data. The dashed yellow lines are what makes it a threat model rather than a plain DFD.
3. Variant: STRIDE-per-Element Matrix
Instead of brainstorming, many teams use this matrix as a checklist: for each element on the DFD, consider only the threats marked for its type. A process can suffer all six; a data flow can only be tampered with, read or blocked. A real model of the shop above produces roughly 4 x 6 + 3 x 4 + 7 x 3 candidate threats, which is why boundary-crossing elements are triaged first.
4. Pros, Cons, and When to Use
Pros
Systematic: every element gets checked against a fixed list, so whole threat classes are not forgotten.
Trust boundaries show exactly where validation, authentication and encryption are needed.
DFDs are quick to draw and readable by developers, security and auditors alike.
Supported by free tools (Threat Dragon, Microsoft TMT) that generate threat lists.
Each numbered threat maps cleanly to a backlog item and a test.
Cons
Generates many low-value threats on large diagrams; triage takes discipline.
Shows data, not control flow or timing, so race conditions and auth sequences are invisible.
Goes stale quickly unless updated with each architecture change.
Says nothing about attacker cost or likelihood (pair with an attack tree).
When to use
Design reviews of a new service or a major change in data handling.
Compliance work that needs evidence of threat analysis (PCI DSS, SOC 2, ISO 27001).
Any system where data crosses network or privilege boundaries.
When not to use
Analysing one protocol step by step (use a sequence diagram).
Prioritising which attack to fix first (use an attack tree with costs).
5. Diagrams-as-Code
OWASP Threat Dragon stores models as JSON; for docs, a Mermaid flowchart with subgraphs as trust boundaries is close enough:
flowchart LR
C[Customer]
subgraph TB1 [DMZ]
W((1.0 Web App))
end
subgraph TB2 [Internal network]
A((2.0 Auth Service))
O((3.0 Order Service))
D1[(D1 Users DB)]
D2[(D2 Orders DB)]
end
P[Payment provider]
C -- HTTPS req --> W
W -- response --> C
W -- session check --> A
W -- order --> O
A -- user row --> D1
O -- order row --> D2
O -- "charge (mTLS)" --> P