Threat Modeling
A structured process for identifying security threats, attack surfaces, and mitigations during system design. STRIDE and DREAD are common frameworks.
What is Threat Modeling?
In short
Threat modeling is a structured process for finding security weaknesses in a system before attackers do, by mapping how data flows, listing what could go wrong at each point, and deciding how to defend against it. Teams usually do it during design using frameworks like STRIDE to enumerate threat categories and rank which ones to fix first.
What it actually is
Threat modeling is the practice of looking at a system the way an attacker would, on purpose and on paper, before you build it or while you change it. You draw how data moves through the system, ask what an attacker could do at each step, and write down both the threats and what you will do about them.
It is not a scan and it is not a penetration test. A scanner checks running code for known bugs. A pen test attacks the deployed system. Threat modeling happens earlier, at the design level, and catches problems that no scanner can see, like a missing authorization check between two services or a token that lives too long.
The output is concrete: a diagram, a list of threats with severity, and a set of mitigations tied to specific components. A good model answers four questions. What are we building, what can go wrong, what are we going to do about it, and did we do a good enough job.
How it works under the hood
Most teams start with a data flow diagram. You draw the external users, the processes (services, APIs), the data stores (databases, queues, S3 buckets), and the arrows between them. Then you draw trust boundaries, the lines where data crosses from a less trusted zone into a more trusted one, like the edge between the public internet and your internal network, or between an unauthenticated and an authenticated request.
Every place an arrow crosses a trust boundary is where you focus. The most common framework for enumerating threats is STRIDE, from Microsoft. It gives you six categories to check each element against: Spoofing (pretending to be someone else), Tampering (changing data in transit or at rest), Repudiation (denying you did something with no audit trail), Information disclosure (leaking data), Denial of service (knocking it offline), and Elevation of privilege (gaining rights you should not have).
Once threats are listed, you rank them. DREAD is one scoring method (Damage, Reproducibility, Exploitability, Affected users, Discoverability), though many teams just use a simple high/medium/low based on likelihood times impact. The point is to spend your limited time on the threats that matter, not to file 200 tickets nobody will close.
For each high priority threat you pick a mitigation: add authentication, sign the request, encrypt the field, rate limit the endpoint, add an audit log. Then you re-check the model, which is why threat modeling is repeated whenever the design changes, not done once and filed away.
When to use it and the trade-offs
Do it for anything that handles money, personal data, authentication, or sits on a trust boundary. A new payments flow, a public API, a multi-tenant database, an admin panel: these are exactly where a missed authorization check becomes a breach. Skip the heavy version for a static marketing page or an internal tool with no sensitive data.
The big payoff is that fixing a design flaw on a whiteboard costs minutes, while fixing it after launch can mean a rewrite, an incident, and a disclosure notice. The IBM Cost of a Data Breach report puts the average breach near 4 to 5 million dollars, and a large share of those start from design level mistakes that a model would have surfaced.
The trade-off is time and discipline. A full STRIDE pass on a complex system can take a day or more and needs people who understand both the architecture and how attacks work. Models also rot. If you threat model once and never update it after the design changes, you get false confidence. Lightweight, frequent modeling beats one heavy document that is out of date by the next sprint.
A concrete example
Take a file upload feature where a user uploads a profile photo that gets stored in an S3 bucket and served back through a CDN. You draw the flow: browser, upload API, S3, CDN, browser. The trust boundary is between the public browser and your API.
Walking STRIDE: Tampering means a user could upload a malicious SVG or an oversized file, so you validate content type and cap the size. Information disclosure means a predictable file URL could let someone enumerate other people's photos, so you use random object keys and signed URLs. Elevation of privilege means the upload endpoint might let one user overwrite another user's object, so you scope the key to the authenticated user ID. Denial of service means someone could spam uploads, so you rate limit.
None of that requires exotic security knowledge. It comes from systematically asking what could go wrong at each arrow and trust boundary, which is the entire discipline in one feature.
Where it is used in production
Microsoft
Created STRIDE and the free Threat Modeling Tool, and bakes threat modeling into its Security Development Lifecycle for products like Windows and Azure.
AWS
Publishes threat modeling guidance and the open source Threat Composer tool, and uses it across service teams as part of its security review process.
OWASP
Maintains the Threat Dragon open source modeling tool and the community Threat Modeling Cheat Sheet that many engineering teams follow.
Runs design level security reviews on new services that are threat modeling in practice, mapping trust boundaries and required controls before launch.
Frequently asked questions
- What is the difference between threat modeling and penetration testing?
- Threat modeling happens at design time on a diagram and finds flaws in the architecture itself, like a missing authorization check. Penetration testing happens against running code and finds exploitable bugs in what was actually built. They are complementary: modeling tells you where to look, pen testing confirms whether the defenses hold.
- What does STRIDE stand for?
- Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. They are six categories of threat, and you check each component or data flow against all six to make sure you have not missed a class of attack.
- When should you do threat modeling?
- During design, before code is written, and again whenever the design changes in a way that touches data flows, trust boundaries, authentication, or sensitive data. It is a repeated activity, not a one time document. The earlier you do it, the cheaper the fixes are.
- Do small teams or startups need to threat model?
- Yes, but keep it lightweight. You do not need a 40 page document. For each new feature that handles auth, money, or user data, spend 30 minutes drawing the flow and asking what could go wrong at each step. That alone catches the most common design mistakes.
- What is DREAD and is it still used?
- DREAD is a scoring method for ranking threats by Damage, Reproducibility, Exploitability, Affected users, and Discoverability. It has fallen out of favor because the scores are subjective and inconsistent between people. Many teams now rank threats with a simpler likelihood times impact rating or use CVSS for known vulnerabilities.
Learn Threat Modeling hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Threat Modeling as part of a larger topic.
Threat Modeling
Systematically identifying and prioritizing threats to your system before attackers find them
intermediate · security architecture
The Lethal Trifecta: Why Prompt Injection Plus Tools Plus Data Is Unsolved
A filter that stops 95 percent of prompt injections still loses to twenty retries. The lethal trifecta is unsolved because detection is the wrong tool. Break it leg by leg instead.
ml-advanced · security
See also
Related glossary terms you might want to look up next.
Penetration Testing
Authorized simulated attacks against a system to find security vulnerabilities before real attackers do. White-hat hackers probe for weaknesses in a controlled environment.
Zero Trust
A security model that never trusts any request by default, even from inside the network. Every request must be authenticated, authorized, and encrypted regardless of origin.
WAF
Web Application Firewall: filters and monitors HTTP traffic between a web application and the internet. Blocks SQL injection, XSS, and other OWASP top-10 attacks.
Incident Response
The structured process for detecting, containing, eradicating, and recovering from security incidents. Includes communication plans, runbooks, and post-incident reviews.
Security Audit
A systematic evaluation of a system's security posture against standards and best practices. Covers access controls, encryption, logging, vulnerability management, and compliance.