Threat modeling
Threat modeling examines what a system does, what could go wrong, and which protections address those risks.
What it means
Threat modeling examines what a system does, what could go wrong, and which protections address those risks. It makes security assumptions visible before they become expensive implementation mistakes. Models should reflect actual data flows and trust relationships, and change when the system changes.
A practical example
A team designing a file-sharing service maps users, storage, processors, and external integrations. It considers unauthorized downloads, malicious uploads, and misuse of sharing links, then turns the relevant defenses into implementation and verification work.
What to check
Identify assets, actors, entry points, data flows, and trust boundaries. Prioritize credible threats in context, assign mitigations, and verify that implemented controls address the original scenarios.
A common pitfall
A diagram without threat analysis and follow-up does not establish protection. Threat modeling is also not a substitute for testing the implemented system.
Think it through
Why revisit the model after adding a partner integration?
Answer: The integration introduces new identities, data flows, and trust assumptions that may create threats absent from the earlier design.
Model the system before debating threats
A threat model starts with an understandable description of the system and its important interactions. Identify users, services, data stores, external dependencies, and trust boundaries. A trust boundary marks a change in assumptions, such as input crossing from a public browser into an authenticated application. Diagrams help when they make those relationships clearer, not when they conceal them behind decorative complexity.
Ask what could go wrong with the behavior the system is supposed to provide. Consider unauthorized reading, modification, impersonation, interruption, and misuse of legitimate features. Prioritize scenarios in context rather than collecting the largest possible list of attack names. The useful result is a set of design decisions, tests, and unresolved questions.
A fictional assessment upload
An academy allows learners to upload assessment files. The team maps the browser, upload endpoint, storage, processing worker, and instructor access. It asks whether a learner can replace another learner's file, whether uploaded content can affect the processing worker, and whether private assessments can become publicly accessible.
Each question leads to a different control or test: server-side ownership checks, safe processing boundaries, and storage access validation. A generic requirement to sanitize uploads would not fully describe those separate risks. Review the model when architecture or use changes, because a new integration can introduce a boundary the original design never considered.
Trace one misuse case
For a harmless training application, draw a request from a user to a database. Mark where identity is established and where permission is enforced. Write one way the request could be misused and one test that would verify the intended protection. Then record a remaining assumption. Threat modeling is effective when it changes implementation and verification rather than remaining an isolated planning document.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Threat Modeling