Threat-Model a Small Web Application
Identify assets, data flows, trust boundaries and prioritized mitigations before deploying a web application.
Introduction
Threat modeling is a structured design review, not an attempt to predict every possible attack. It asks what the application values, where data moves, which boundaries change trust and what could go wrong. Doing this before deployment makes security decisions cheaper and easier to verify.
How the topic works
Start with assets such as accounts, session tokens, private tasks and availability. Draw the browser, application, database and external services, then label data flows and trust boundaries. For each component, consider spoofing, tampering, information disclosure, denial of service and privilege misuse. Prioritize by plausible impact and likelihood in this specific design.
Practical workflow
- Define scope, users, sensitive assets and explicit assumptions.
- Draw components, data stores, external services and directional flows.
- Mark every point where data or identity crosses a trust boundary.
- List threats and existing controls, then rank the unresolved risks.
- Assign mitigations, owners, verification tests and a review date.
Tools and technologies
- A data-flow diagram
- A threat checklist such as STRIDE
- A risk register
Example
A browser sends a session cookie to the application, which reads tasks from a database. Risks include stolen sessions, unauthorized task access and malicious input. Mitigations include secure cookie settings, server-side authorization on every task query, input validation and safe output encoding.
Common mistakes
- Listing generic threats without connecting them to a data flow
- Treating login as sufficient authorization
- Recording mitigations without tests or owners
Security and best practice
Model only systems you are authorized to review. Keep diagrams free of real credentials, internal addresses and sensitive production details when publishing portfolio work.
Portfolio task
Key takeaways
- Assets and flows focus the review.
- Trust boundaries show where validation and authorization matter.
- A mitigation is incomplete until it can be verified.