Threat modeling is a design-time practice for analysing a system to find potential threats, rank them and decide on mitigations. Teams typically ask four questions: what are we building, what can go wrong, what will we do about it, and did we do a good job.
Why it matters
Fixing a design flaw after release costs far more than fixing it on a diagram. Modeling forces teams to map assets, trust boundaries and data flows, then consider how each might be abused. Frameworks help structure the thinking, for example STRIDE, which groups threats into spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
Example
A team designs a file-upload feature and draws the flow from browser to storage. At the boundary between untrusted uploads and the server, they list threats: oversized files, malicious content types, path tricks in names. Each gets a mitigation, such as size limits, content validation, generated storage names and a separate storage domain.
Common mistakes
- Doing it once and never revisiting after the design changes.
- Making it the security team's job alone rather than involving developers.
- Producing a long list without prioritising by impact and likelihood.
- Skipping the data flow diagram and guessing.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.