The clearest way to explain threat modeling is with a concrete threat model example rather than an abstract definition. Below is a complete walkthrough of modeling a simple feature — a user login flow that leads into a payment step — using the STRIDE framework, from drawing the system to writing down mitigations a team could actually ticket and ship.
Step 1: Scope the System
Before threats can be identified, the system needs a boundary. For this example, assume a web app where a user logs in with a password, then submits a payment to a third-party payment processor. The components in scope: the browser, the login API, the session store, the payment API, and the external payment processor.
Step 2: Draw the Data Flow Diagram
A data flow diagram doesn't need to be fancy — boxes for processes, cylinders for data stores, arrows for data flow, and dashed lines for trust boundaries. In this example:
- Trust boundary 1: between the user's browser (untrusted) and the login API (trusted backend).
- Trust boundary 2: between the application backend (your trust) and the external payment processor (a third party you don't control).
- Data store: a session table holding session tokens after login.
Drawing this out is often where teams discover a flow they didn't fully understand — for instance, realizing that a "temporary" debug endpoint bypasses the trust boundary entirely.
Step 3: Identify Threats With STRIDE
STRIDE assigns one threat category per letter, walked against each element of the diagram.
| Element | Threat Category | Specific Threat |
|---|---|---|
| Login API | Spoofing | Attacker guesses or brute-forces a password |
| Session store | Tampering | Session token is predictable or can be forged |
| Login API | Repudiation | No log of failed login attempts |
| Payment API | Information Disclosure | Card data logged in plaintext by mistake |
| Payment API | Denial of Service | Unthrottled endpoint allows request flooding |
| Session store | Elevation of Privilege | Session fixation lets an attacker reuse a victim's session ID |
Each row here is a genuinely plausible threat for this kind of flow, not a hypothetical edge case — session fixation and unthrottled payment endpoints show up regularly in real security assessments.
Step 4: Decide What to Do About Each Threat
For each row, the team picks: mitigate, eliminate, transfer, or accept.
- Spoofing (brute force): Mitigate with rate limiting and account lockout after repeated failures, plus optional MFA.
- Tampering (session token): Mitigate by generating cryptographically random, sufficiently long session tokens and rotating them on privilege change.
- Repudiation (no login log): Mitigate by logging authentication attempts with timestamp, source IP, and outcome to an append-only log.
- Information Disclosure (card data in logs): Eliminate by ensuring the logging layer never receives raw payment fields — mask or omit them before they reach any log sink.
- Denial of Service (unthrottled endpoint): Mitigate with rate limiting and a WAF rule on the payment endpoint.
- Elevation of Privilege (session fixation): Mitigate by regenerating the session ID on login, never reusing a pre-authentication session token post-login.
Step 5: Track Mitigations as Real Work
Each decision above becomes a ticket, not a note in a slide deck. This is the step teams skip most often, and it's the one that actually determines whether the threat model changes anything. A threat model that never produces a backlog item is a documentation exercise, not a security control.
What Makes This Threat Model Example Realistic?
Every threat listed here maps to a documented, common vulnerability class — brute-force login, session fixation, sensitive data exposure in logs, unthrottled endpoints — the kind of findings that show up in real SAST and DAST scans and penetration test reports. The value of walking through an example like this is recognizing that the same six-step process applies whether the system is a login flow or a distributed microservice architecture; only the specific threats and diagram complexity change.
FAQ
Do I need special software to build a threat model?
No — a whiteboard or a simple diagramming tool is enough for most teams. Dedicated threat modeling tools help at scale (large systems, many services) but aren't required to get value from the process.
How long should a threat modeling session take?
For a feature the size of this example, one to two hours is typical, including diagramming. Larger systems get broken into smaller sessions per component rather than one long marathon.
What's the difference between STRIDE and other frameworks like PASTA?
STRIDE is a threat categorization mnemonic, quick to apply per-element. PASTA is a broader, risk-centric process that incorporates business impact and attacker motivation. Many teams use STRIDE for individual feature reviews and reserve PASTA-style analysis for higher-stakes systems. These are two of the most common types of threat models in practice, alongside attack trees and OWASP's own dread-based scoring; the walkthrough above uses STRIDE because it maps cleanly onto a small, well-scoped flow like this one.
Who should be in the room for a threat modeling session?
At minimum, the engineer who knows the system's design and someone with security context. Larger sessions benefit from product and ops input, since they surface assumptions the engineer closest to the code might not think to question.