Threat Modeling for Web Applications: A Practical Guide

Threat modeling is the structured process of identifying what can go wrong in your web application, who might attack it, and where your defenses are weakest. It turns vague security concerns into concrete, prioritized risks tied to your actual architecture. Teams that threat model during design catch categories of vulnerabilities that scanners and pen tests routinely miss — logic flaws, trust boundary violations, and missing authorization checks that only surface when you reason about how data flows through your system.

Microsoft's Security Development Lifecycle data shows that teams performing threat modeling during design reduce critical vulnerabilities by 20–50% compared to teams relying solely on testing-phase security activities.

Scan your code for the vulnerabilities threat modeling uncovers — get your first Rafter report in under two minutes.

What Threat Modeling Covers

A threat model answers four questions:

What are you building? — Diagram your application's components, data flows, trust boundaries, and external dependencies.
What can go wrong? — Systematically identify threats using a framework (see below).
What are you going to do about it? — Define mitigations, accept residual risk, or redesign.
Did you do a good job? — Validate that mitigations are implemented and assumptions hold.

The output is a living document: a data flow diagram annotated with threats, their severity, and the controls that address each one.

Frameworks: STRIDE, PASTA, and LINDDUN

STRIDE is the most widely used framework for web application threat modeling. Developed at Microsoft, it categorizes threats into six types:

Spoofing — impersonating another user or system
Tampering — modifying data in transit or at rest
Repudiation — denying actions without accountability
Information disclosure — exposing data to unauthorized parties
Denial of service — making the application unavailable
Elevation of privilege — gaining unauthorized access levels

Apply STRIDE to each element in your data flow diagram. For every component and data flow, ask which of the six threat types apply.

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric framework that works backward from business impact. Heavier than STRIDE but produces risk scores tied directly to business value.

LINDDUN focuses on privacy threats: linking, identifying, non-repudiation, detecting, data disclosure, unawareness, and non-compliance. Use it alongside STRIDE when your application handles personal data subject to GDPR or CCPA.

When to Threat Model

Threat model at three points:

Design phase — before writing code for a new application or service. This is where threat modeling delivers the highest ROI.
Major feature additions — new authentication flows, third-party integrations, API surface expansion, or changes to data storage.
Architectural changes — migrating to microservices, adding a CDN, changing cloud providers, or introducing new trust boundaries.

You do not need to threat model every sprint. Model when the attack surface changes.

A Lightweight Agile Approach

Full threat models can take days. For agile teams, a lightweight approach keeps modeling practical:

Whiteboard the data flow — 15 minutes. Draw your components, data stores, external systems, and the arrows between them. Mark trust boundaries.
Walk STRIDE per element — 20 minutes. For each component and flow, ask: can it be spoofed, tampered with, repudiated, disclosed, denied, or escalated?
Rank and record — 10 minutes. Score threats by likelihood and impact. Log them as issues in your backlog.
Validate with scanning — Automated security scanning confirms that your assumptions hold in the actual code. Threat modeling predicts where vulnerabilities should appear; vulnerability scanning proves whether they do.

This 45-minute exercise catches architectural risks that no amount of code-level scanning can find. Run it once per major feature, and your threat model stays current without becoming a bottleneck.

Start validating your threat model assumptions with Rafter — automated scanning on every commit.

What Threat Modeling Covers

A threat model answers four questions:

What are you building? — Diagram your application's components, data flows, trust boundaries, and external dependencies.

What can go wrong? — Systematically identify threats using a framework (see below).

What are you going to do about it? — Define mitigations, accept residual risk, or redesign.

Did you do a good job? — Validate that mitigations are implemented and assumptions hold.

The output is a living document: a data flow diagram annotated with threats, their severity, and the controls that address each one.

Frameworks: STRIDE, PASTA, and LINDDUN

STRIDE is the most widely used framework for web application threat modeling. Developed at Microsoft, it categorizes threats into six types:

Spoofing — impersonating another user or system

Tampering — modifying data in transit or at rest

Repudiation — denying actions without accountability

Information disclosure — exposing data to unauthorized parties

Denial of service — making the application unavailable

Elevation of privilege — gaining unauthorized access levels

Apply STRIDE to each element in your data flow diagram. For every component and data flow, ask which of the six threat types apply.

When to Threat Model

Threat model at three points:

Design phase — before writing code for a new application or service. This is where threat modeling delivers the highest ROI.

Major feature additions — new authentication flows, third-party integrations, API surface expansion, or changes to data storage.

Architectural changes — migrating to microservices, adding a CDN, changing cloud providers, or introducing new trust boundaries.

You do not need to threat model every sprint. Model when the attack surface changes.

A Lightweight Agile Approach

Full threat models can take days. For agile teams, a lightweight approach keeps modeling practical:

Whiteboard the data flow — 15 minutes. Draw your components, data stores, external systems, and the arrows between them. Mark trust boundaries.

Walk STRIDE per element — 20 minutes. For each component and flow, ask: can it be spoofed, tampered with, repudiated, disclosed, denied, or escalated?

Rank and record — 10 minutes. Score threats by likelihood and impact. Log them as issues in your backlog.

Validate with scanning — Automated security scanning confirms that your assumptions hold in the actual code. Threat modeling predicts where vulnerabilities should appear; vulnerability scanning proves whether they do.

This 45-minute exercise catches architectural risks that no amount of code-level scanning can find. Run it once per major feature, and your threat model stays current without becoming a bottleneck.