What Is Threat Modeling?
Threat modeling is a structured way to answer one question before an attacker does: what could go wrong here? You map what you are building, identify what could threaten it, decide what to do about each threat, and check your work. It turns vague security anxiety into a ranked, addressable list.
What four questions does a threat model answer?#
The whole practice reduces to four questions, popularized by security engineer Adam Shostack:
- What are we building? Diagram the system, its components, and how data flows between them.
- What can go wrong? Enumerate threats against each component and data flow.
- What are we going to do about it? Decide to mitigate, eliminate, transfer, or accept each threat.
- Did we do a good job? Review the model against the finished system and update it.
Skip the first question and you model an imaginary system. Skip the last and your model rots.
Where do the threats actually come from?#
Most real threats cluster at trust boundaries — the lines where data moves from something you control to something you do not, or from lower privilege to higher. A form submission crossing from browser to server, a file arriving from a third party, a token minted by one service and honored by another: each boundary is where a threat model earns its keep.
To generate threats without staring at a blank page, apply STRIDE to each element:
| Category | The question it prompts | Example |
|---|---|---|
| Spoofing | Can someone pretend to be someone else? | Forged session token |
| Tampering | Can data be modified in transit or at rest? | Altered price field |
| Repudiation | Can an actor deny an action? | No audit log of a transfer |
| Information disclosure | Can data leak to the wrong party? | Verbose error messages |
| Denial of service | Can availability be destroyed? | Unbounded request loop |
| Elevation of privilege | Can someone gain rights they shouldn’t have? | Broken access control |
How do you keep a threat model from becoming a document nobody reads?#
Keep it small and living. Model one feature or data flow at a time, write down only the threats you will actually act on, and store the model beside the code so it changes when the code changes.
Threat modeling underpins nearly everything else in security — it tells you which attack surface matters and where defense in depth should go. Start from the Security Fundamentals hub to see how the pieces connect.
Frequently asked questions#
When should you do threat modeling?
As early as possible — ideally at the design stage, before code exists, when changes are cheap. But threat modeling is not one-and-done: revisit the model whenever the architecture, data flows, or trust boundaries change. A model that never gets updated slowly stops describing the real system.
What is STRIDE?
STRIDE is a mnemonic for six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Walking each component of a system against these six prompts is a fast, repeatable way to surface threats without needing to imagine attacks from scratch.
Do you need a diagram to threat model?
A data-flow diagram helps enormously because most threats live at trust boundaries — the points where data crosses from one level of trust to another — and a diagram makes those boundaries visible. But a whiteboard sketch is enough; the value is in the structured conversation, not the artifact.