June 26, 2026 · Ironimo Security Team

Threat Modeling for Web Applications: STRIDE, PASTA, and Practical Threat Analysis

Most teams approach security testing backwards. They spin up a scanner, run it against a staging environment, triage a list of findings, and call it done. The problem: they never asked what they were actually trying to protect, who might want to attack it, or how a real adversary would approach the system. That's threat modeling's job — and skipping it means your testing effort is guided by tool coverage rather than actual risk.

Threat modeling is not a compliance checkbox or a whiteboard exercise that lives in a wiki and never gets read again. Done well, it produces a ranked list of attack scenarios specific to your application — scenarios you then verify with real tests. This guide covers the two most practical methodologies for web applications (STRIDE and PASTA), how to build the data flow diagrams that anchor both, and how to translate a threat model into a test plan.

What Threat Modeling Actually Is

The simplest definition: threat modeling is the process of identifying what could go wrong with a system before it goes wrong. For web applications, that means answering four questions:

1. What are we building? — the system's components, data flows, and trust boundaries
2. What can go wrong? — the threats relevant to this specific system
3. What are we going to do about it? — mitigations and countermeasures
4. Did we do a good enough job? — validation that mitigations are implemented and effective

The output of a threat model is not a document — it's a prioritized list of threats that drives your security testing, your architecture decisions, and your backlog. If your threat model isn't feeding tickets into your sprint, it isn't working.

Threat modeling is most valuable at two points: early in design (when changing architecture is cheap) and before a major release or significant feature addition (when the attack surface changes meaningfully). Running it once and forgetting it is almost as bad as not running it at all.

STRIDE: The Developer-Friendly Framework

STRIDE was developed at Microsoft in the late 1990s and remains the most widely adopted threat modeling methodology for web applications. The acronym maps to six threat categories that cover the full space of what can go wrong with a software system. Critically, each category maps cleanly to a security property that your system is supposed to provide — which makes it easy to check mitigations.

Spoofing

Spoofing threats target authentication — the system's ability to verify that entities are who they claim to be. For web apps, this includes session fixation attacks, JWT algorithm confusion (accepting alg: none), predictable session token generation, OAuth token leakage, and credential stuffing against login endpoints. The question to ask for every trust boundary crossing: how does the receiving component know who sent this request, and can that identity be forged?

Tampering

Tampering threats target data integrity — inputs the system trusts that an attacker can modify. In web applications, this means HTTP parameters (query strings, POST bodies, hidden form fields), cookies that encode state, JWT payloads without signature verification, and indirect object references where the client controls which record gets operated on. Mass assignment vulnerabilities are a classic tampering threat: the application trusts the client to send only the fields it should be able to set.

Repudiation

Repudiation is the threat that a user can deny having taken an action, and the system cannot prove otherwise. This matters most for high-value actions: financial transactions, admin operations, data deletion. Countermeasures include tamper-evident audit logs (append-only, signed), server-side logging of all state-changing requests, and immutable event sourcing architectures. Repudiation threats often get skipped in threat models because they don't produce obvious exploit scenarios — but they're critical for fraud investigation and compliance.

Information Disclosure

Information disclosure covers unintended data exposure: verbose error messages, directory listings, backup files left in web roots (.git, .env, backup.sql.gz), over-privileged API responses returning more fields than the client needs, and timing side-channels in authentication flows. IDOR vulnerabilities live here too — the user can read records they shouldn't have access to, even if the data itself isn't sensitive to an outsider.

Denial of Service

DoS threats for web applications go well beyond volumetric network floods. Application-layer DoS is usually more interesting from a threat modeling perspective: expensive regex patterns with catastrophically backtracking inputs (ReDoS), unauthenticated endpoints that trigger heavy DB queries, resource exhaustion via large file uploads without limits, and slowloris-style connection exhaustion. For each computationally expensive operation in your system, ask: can an unauthenticated attacker trigger this at scale?

Elevation of Privilege

EoP threats target authorization — the gap between what a principal is authenticated as and what they can actually do. Horizontal privilege escalation (accessing another user's data) and vertical escalation (accessing admin functionality as a regular user) both fall here. Broken access control is OWASP's A01 for a reason: it's the most common critical finding in real applications. STRIDE's EoP category should map directly to your authorization model — every role boundary in your system needs an explicit threat entry.

When STRIDE Works Well

STRIDE is best suited for component-level analysis against a data flow diagram. You walk each element in the DFD — each process, data store, data flow, and external entity — and ask which STRIDE threats apply. It's systematic, teachable, and doesn't require deep attacker mindset to get started. Development teams with no prior security background can run a productive STRIDE session in an afternoon. It's also the methodology most directly supported by Microsoft Threat Modeling Tool.

PASTA: The Risk-Driven Alternative

PASTA (Process for Attack Simulation and Threat Analysis) takes a different angle. Where STRIDE starts with the system and asks what can go wrong, PASTA starts with business objectives and works down to technical attack scenarios. It's more comprehensive and more effort — typically suited to AppSec teams working on critical systems, compliance-heavy environments, or situations where you need to quantify risk in business terms.

PASTA has seven stages:

1. Define Objectives — What are the business and security objectives? What data is most valuable? What's the impact of a breach? This grounds the entire analysis in something the business actually cares about.
2. Define the Technical Scope — What's in scope? Application components, infrastructure, third-party integrations, deployment environment. Draw the boundaries.
3. Application Decomposition — Break the application into data flows, trust levels, entry points, and assets. This produces the same artifact as the DFD step in STRIDE.
4. Threat Analysis — Review threat intelligence, CVE databases, and known attack patterns relevant to your technology stack. What threats exist in the wild that apply here?
5. Vulnerability and Weakness Analysis — Map existing vulnerabilities (from prior scans, code review, bug reports) to the threat catalog. Where do known weaknesses align with identified threats?
6. Attack Enumeration and Modeling — Build attack trees and attack patterns for the highest-risk threat/vulnerability combinations. This is where you simulate how an attacker would chain weaknesses together.
7. Risk and Impact Analysis — Score each attack scenario by likelihood and impact. Produce a prioritized risk register that feeds security controls, testing priorities, and remediation backlog.

STRIDE vs. PASTA: Which One to Use

Use STRIDE when you need to move fast, when you're working with development teams who don't have a security background, or when you're doing component-level analysis of a specific feature or service. It's practical, fast, and produces actionable output.

Use PASTA when you need to tie security risk to business impact — when a CISO needs to explain to a board why a particular control investment is justified, when you're doing a full-system analysis for a major release, or when regulatory requirements demand a documented risk assessment methodology. PASTA's output is a risk register that business stakeholders can reason about; STRIDE's output is a threat list that developers can test against.

For most DevSecOps teams, STRIDE is the right default. Run PASTA for annual full-system reviews or when scoping security investment.

Data Flow Diagrams: The Foundation of Both

Both STRIDE and PASTA depend on a data flow diagram (DFD). A DFD is not an architecture diagram — it's a representation of how data moves through your system, which components process it, and where trust boundaries lie. You cannot run a meaningful threat model without one.

A DFD has four element types:

• External entities — actors outside the system boundary: users, third-party APIs, partner services. Drawn as rectangles.
• Processes — components that transform or act on data: your application server, a background worker, an API gateway. Drawn as circles or rounded rectangles.
• Data stores — anywhere data is persisted: databases, caches, file systems, message queues. Drawn as parallel horizontal lines.
• Data flows — the connections between elements, with direction arrows showing how data moves and labels describing what's being transferred.

Trust boundaries are the most important element in the DFD for security purposes. A trust boundary is a line where the trust level of the data changes — typically where data crosses from one security domain into another. Anywhere data crosses a trust boundary is a potential threat surface: user input entering your application, your application making an outbound call to a third-party API, a microservice calling another microservice across a network segment.

Practical guidance: start at Level 0 (the whole system as a single process) and expand to Level 1 (major subsystems) before going further. Most web applications only need a Level 1 DFD to run a useful STRIDE analysis. Going deeper than Level 2 produces diminishing returns and analysis paralysis.

For a typical web application, a Level 1 DFD includes: browser (external entity) → load balancer/CDN → application server(s) → database, cache, and message queue (data stores) → external APIs and email/SMS providers (external entities). Mark trust boundaries at the network perimeter, between front-end and back-end, and at every third-party integration.

The Practical Threat Modeling Process

Here's a process that works for a team that's never done threat modeling before, produces real output in a single working session, and doesn't require expensive tools or consultants.

Step 1: Assemble the Right People (30 minutes)

You need at least one person who understands the system architecture, one who understands the business context (what data is valuable, what failure looks like), and one with security knowledge to drive the threat enumeration. For most teams, this is a lead engineer, a product manager, and someone from the security function. Four to six people is the practical ceiling — larger groups slow down without adding coverage.

Step 2: Draw the DFD Together (60 minutes)

Do this on a shared whiteboard (physical or virtual). Start with the external entities — who or what interacts with the system from outside. Then add your major processes. Then add data stores. Then draw the data flows with labels. Finally, draw trust boundary lines. The act of drawing together surfaces disagreements about how the system actually works, which is itself valuable.

Step 3: Enumerate Threats (90 minutes)

Walk each trust boundary crossing in the DFD and apply the STRIDE categories. For each element crossing a boundary, ask: can this be spoofed? can this data be tampered with in transit? can actions be repudiated? is confidential data exposed? can this be used to cause denial of service? does this flow enable privilege escalation? Write down every threat you identify, even ones that seem unlikely or already mitigated — you'll score them next.

Step 4: Score and Prioritize (45 minutes)

For each threat, assign a rough risk score. DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) is one scoring model; CVSS base score is another; a simple 3x3 likelihood/impact matrix works fine. The goal is relative prioritization, not precise numbers. Rank your top 10 threats.

Step 5: Define Mitigations and Test Cases

For each high-priority threat, define two things: the countermeasure that should prevent it, and the test that would verify whether the countermeasure works. This is what converts the threat model from a document into a testing agenda.

Turning Threats into Test Cases

The connection between STRIDE categories and OWASP testing methodology is direct. Here's how to map your enumerated threats to specific tests:

The key discipline here is specificity. Don't write "test for IDOR" as a test case. Write: "Authenticate as user A, create a resource, note the resource ID, authenticate as user B, attempt GET/PUT/DELETE on that resource ID — verify that user B receives a 403." Specific, reproducible, with a defined pass/fail condition. That's a test case.

For each threat in your model, write test cases at this level of specificity. The threat model tells you what to test; the OWASP Testing Guide tells you how to test it; the test case you write tells you whether you actually tested it.

Tools for Threat Modeling

OWASP Threat Dragon

An open-source threat modeling tool with a web-based DFD editor and built-in STRIDE support. It stores models as JSON files that can live in your repository alongside code. This is the right choice for teams who want to treat threat models as code artifacts, version-controlled and reviewed alongside architectural changes. It's not the most polished tool, but it's free, actively maintained, and produces structured output that's machine-readable.

Microsoft Threat Modeling Tool

The reference implementation for STRIDE, built by the team that invented the methodology. Windows-only, which is a limitation for many teams, but the tool includes a built-in STRIDE template with automatic threat generation — draw your DFD and the tool suggests threats based on element types and trust boundary crossings. Useful for teams new to STRIDE who want guardrails during enumeration.

IriusRisk and ThreatModeler

Commercial platforms that integrate threat modeling into development workflows — Jira integration, automated threat libraries, compliance mapping. Justified for large AppSec programs that need to scale threat modeling across multiple teams. Overkill for most organizations.

Miro / draw.io with a STRIDE Template

Pragmatically, many teams do their best threat modeling on a shared Miro board with a custom DFD template and a STRIDE threat table maintained in a spreadsheet. This is not ideal for tooling integration but removes all friction — and a threat model that actually gets done is worth more than a perfect process that never runs. If your team is resistant to dedicated tooling, start here and migrate later.

Common Mistakes

Scope Creep: Modeling Everything at Once

The most common failure mode is trying to threat model the entire system in one session. The scope becomes overwhelming, the session runs long, everyone gets fatigued, and the output is a vague list of generic threats that produces no actionable tests. Instead: scope to a single feature, a specific data flow, or a new integration. A tight scope produces better analysis than a broad one. You can always run multiple sessions.

Too Much Theory, Not Enough System Knowledge

Threat modeling sessions that focus on STRIDE definitions and methodology mechanics rather than the actual system are a waste of time. The methodology is a framework for organizing discussion — it's not the substance of the session. Keep the DFD in front of the room at all times and anchor every threat to a specific element in the diagram. "What could go wrong with this authentication flow?" is more productive than "what are examples of spoofing threats?"

Treating Mitigations as the End State

Identifying a threat and noting "mitigated by authentication" is not enough. Authentication is frequently broken. The threat model needs to produce a test that verifies the authentication actually works as intended, handles edge cases correctly, and can't be bypassed. A threat model without corresponding test cases has no feedback loop — you have no way to know whether your mitigations are effective.

Never Updating It

A threat model that reflects last year's architecture is worse than no threat model, because it creates false confidence. Trigger a threat model update for: new authentication flows, new external integrations, significant data model changes, new user roles or trust levels, infrastructure migrations. Put it in your definition of done for major features.

Skipping It Entirely Because Testing Covers It

Security testing without a threat model is coverage without direction. You'll find whatever your scanner finds — which is determined by the tool's detection capabilities, not by your application's actual risk profile. Threat modeling tells you what to look for; testing tells you whether it's there. The two are complementary, not substitutes.

Threat modeling is the practice that separates teams who understand their security posture from teams who hope their scanner caught everything. It's not expensive or time-consuming once the practice is established — a mature team can run a focused threat model session in half a day and produce a week's worth of targeted testing work. The investment pays back immediately in the quality of your test coverage and the relevance of what you find.

The goal is not a perfect document. It's a shared understanding of where your system is vulnerable, grounded in how your system actually works, that drives specific tests you can run and verify.