Threat Modelling for Web Applications: How Product Teams Find Risks Before Release
How product teams threat model web applications: the four key questions, data flow diagrams, STRIDE, prioritising risks and turning findings into work.
How do product teams threat model a web application?
Draw a data flow diagram of the feature or system with its trust boundaries, walk through each element asking what could go wrong (STRIDE is a useful checklist), rate the threats by likelihood and impact, choose mitigations and add them to the backlog with owners, record accepted risks, and check later that the mitigations work. A one-to-two-hour workshop at design time catches problems that are expensive to fix after release.
This guide is for product managers, designers and engineers. It is educational; ZSpace Labs does not provide security assessments. For AI-specific threats, see AI application threat modelling.
Key takeaways
- Answer the four questions: what, what can go wrong, what will we do, did it work.
- Diagram data flows and trust boundaries.
- Use STRIDE to prompt threats per element.
- Turn mitigations into backlog items with owners.
- Repeat for significant changes.
The four questions
The Threat Modeling Manifesto organises the work around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job? OWASP's threat modelling guidance describes methods and tools. Keep the method simple enough that teams use it routinely.
STRIDE applied to web apps
| Threat | Web example | Typical mitigation |
|---|---|---|
| Spoofing | Stolen session or weak sign-in | MFA, passkeys, secure session handling |
| Tampering | Changing prices or IDs in requests | Server-side validation and authorisation |
| Repudiation | User denies an action | Audit logs with integrity |
| Information disclosure | Another tenant's data in a response | Object-level authorisation, tenant isolation |
| Denial of service | Expensive endpoints abused | Rate limits, quotas, caching |
| Elevation of privilege | User reaches admin functions | Central authorisation, least privilege |
Running a workshop
- Invite product, design, engineering and someone who knows operations.
- Scope one feature or flow, not the whole system.
- Draw the diagram together: users, components, data stores, external services, trust boundaries.
- Walk each flow crossing a boundary and list threats.
- Rate quickly (high, medium, low) and agree mitigations.
- Record decisions and accepted risks; create backlog items.
From findings to verification
Mitigations should become stories with acceptance criteria and tests, such as automated checks that users cannot access other tenants' records. Review the model when architecture changes, after incidents and before independent testing, so testers can focus on the riskiest areas. See secure web application development and penetration testing.
Hypothetical example: a document sharing feature
This example is hypothetical. A SaaS team planning external document sharing ran a 90-minute session. The diagram showed links crossing from the public internet into the document store. STRIDE prompted threats including guessable links, links that never expire, and missing logs of who viewed what. The team chose unguessable tokens with expiry, optional passwords, access logging and per-tenant controls to disable external sharing, and added tests for each.
Common mistakes
- Treating threat modelling as a one-off document.
- Modelling the whole system at once and never finishing.
- No owners for mitigations.
- Only engineers in the room.
- Assuming it replaces testing.
Related guides
- API security best practices for common API threats.
- Multi-tenant SaaS architecture for isolation.
- Software supply chain security for build threats.
- Privacy by design for privacy threats.
Conclusion
Threat modelling helps teams find security and privacy risks while they are cheap to fix. Keep it simple, do it routinely for significant changes, turn findings into tested work, and use independent testing to check the results. Upload features deserve their own controls; see secure file uploads.
Designing a feature with sensitive data?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure web applications. We do not provide security assessments, but we build threat modelling into how we design and develop software.
Common questions.
A structured way to think about what could go wrong with a system from a security and privacy perspective, before or while building it, and to decide what to do about it. The Threat Modeling Manifesto frames it as four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job?