Threat Modeling with STRIDE

STRIDE: The Six Categories of Threat

A Systematic Way to Think Like an Attacker

STRIDE is a threat classification model developed by Microsoft that categorizes threats into six types. Each letter stands for a different way an attacker can violate a security property:

S — Spoofing

An attacker impersonates something or someone else. Spoofing violates authentication — the system cannot correctly identify who or what is making a request.

Examples:

An attacker steals a session cookie and uses it to impersonate a logged-in user
An attacker sends an email with a spoofed From: address
An attacker modifies the Host header in an HTTP request to impersonate a virtual host
An attacker clones a mobile app's certificate pinning bypass to impersonate the app

The common thread: the system trusts an identity that it should not. The control is strong authentication — MFA, certificate validation, token signing.

T — Tampering

An attacker modifies data or code in transit or at rest. Tampering violates integrity.

Examples:

An attacker modifies a financial transaction amount in an API request
An attacker alters a software update package before it reaches users
An attacker edits a configuration file to disable security controls
An attacker modifies a JWT token's payload without invalidating the signature

The common thread: the system accepts data without verifying it has not been altered. The control is integrity verification — digital signatures, HMACs, checksums.

R — Repudiation

An attacker denies having performed an action, and the system cannot prove otherwise. Repudiation violates non-repudiation — the ability to trace actions to a specific actor.

Examples:

A user deletes a record and claims they never did it
An attacker uses a shared account and denies performing a specific action
A system processes a transaction without logging who initiated it

The common thread: the system does not create sufficient evidence to hold actors accountable. The control is comprehensive audit logging — immutable logs, digital signatures on log entries, timestamped records.

I — Information Disclosure

An attacker gains access to data they should not see. Information disclosure violates confidentiality.

Examples:

An API returns more data than the user is authorized to see (IDOR)
An error message reveals database schema or stack traces
A backup file is stored in a publicly accessible location
A memory leak exposes sensitive data in a core dump

The common thread: the system reveals data to unauthorized parties. The control is access control, encryption, and proper error handling.

D — Denial of Service

An attacker prevents legitimate users from accessing a system or service. Denial of service violates availability.

Examples:

An attacker floods a server with requests until it cannot respond to legitimate users
An attacker triggers an expensive operation (e.g., a complex database query) repeatedly
An attacker exploits a memory leak to exhaust server resources
An attacker locks all user accounts through password spraying

The common thread: the system cannot handle the volume or nature of requests. The control is rate limiting, resource quotas, and graceful degradation.

E — Elevation of Privilege

An attacker gains access to functionality or data beyond their authorized level. Elevation of privilege violates authorization.

Examples:

A standard user exploits a flaw to gain admin access
An attacker manipulates a user ID parameter to access another user's data (IDOR/BOLA)
An attacker exploits a race condition to escalate privileges during a permission check
An attacker uses a service account with excessive permissions to access restricted resources

The common thread: the system does not properly enforce what an authenticated user is allowed to do. The control is proper authorization checks on every request, not just at login.

Why STRIDE Works

STRIDE works because it is exhaustive within its scope. Every threat to a software system fits into at least one of these six categories. By systematically asking "can an attacker spoof, tamper, repudiate, disclose, deny, or elevate at this point?" you avoid the ad-hoc approach where you only think of threats you have personally encountered.

The model also maps directly to security properties:

Spoofing → Authentication
Tampering → Integrity
Repudiation → Non-repudiation
Information Disclosure → Confidentiality
Denial of Service → Availability
Elevation of Privilege → Authorization

This mapping means that when you identify a STRIDE threat, you immediately know which security property is at risk and which class of controls to consider.

Data Flow Diagrams and Trust Boundaries

Drawing the System So You Can Attack It

A data flow diagram (DFD) is the primary artifact in STRIDE-based threat modeling. It shows how data moves through a system, where it is processed, where it is stored, and — critically — where trust boundaries exist.

DFD Elements

A DFD uses four basic symbols:

Process (circle): A component that transforms data — a web server, a microservice, a batch job. Each process is a place where data is handled and where threats can exist.
Data store (two parallel lines or a cylinder): A place where data persists — a database, a file system, a message queue. Data stores are targets for tampering and information disclosure.
Data flow (arrow): The movement of data between processes, data stores, and external entities. Data flows are targets for tampering and information disclosure (if intercepted).
External entity (rectangle): Something outside the system that interacts with it — a user, a third-party API, a mobile app. External entities are sources of spoofing threats.

Trust Boundaries

A trust boundary is a line drawn on the DFD where the level of trust changes. When data crosses a trust boundary, it moves from a context where it is trusted to a context where it must be validated.

Common trust boundaries:

Between the internet and your network perimeter
Between the web server and the application server
Between the application server and the database
Between a user's browser and your web application
Between two microservices with different authentication requirements
Between an untrusted input (user input) and a trusted internal process

The rule: every data flow that crosses a trust boundary must be validated. If data crosses a trust boundary without validation, you have identified a threat.

Building a DFD: Step by Step

Let's model a simple e-commerce application:

[User] --(HTTPS)--> [Web Server] --(internal)--> [App Server] --(SQL)--> [Database]
                                      |
                                      +--(API)--> [Payment Gateway]

Trust boundaries:

Between User and Web Server (internet → perimeter)
Between Web Server and App Server (perimeter → internal)
Between App Server and Database (application → data layer)
Between App Server and Payment Gateway (internal → external)

Now apply STRIDE to each element:

User → Web Server (data flow crossing trust boundary):

Spoofing: Can an attacker impersonate a user? → Session management, MFA
Tampering: Can an attacker modify the request? → TLS, input validation
Repudiation: Can a user deny a purchase? → Audit logging
Information Disclosure: Can an attacker intercept the request? → TLS, HSTS
Denial of Service: Can an attacker flood the web server? → Rate limiting, WAF
Elevation of Privilege: Can a user access admin endpoints? → Authorization checks

Web Server (process):

Spoofing: Can an attacker spoof the web server to the app server? → Mutual TLS, service authentication
Tampering: Can an attacker modify data in the web server's memory? → Input validation, secure coding
Repudiation: Can the web server deny processing a request? → Request logging
Information Disclosure: Can an attacker read the web server's logs or config? → Access control, log protection
Denial of Service: Can an attacker exhaust the web server's resources? → Resource limits, auto-scaling
Elevation of Privilege: Can an attacker exploit the web server to gain OS-level access? → Patching, least privilege

App Server → Database (data flow):

Spoofing: Can an attacker impersonate the app server to the database? → Database authentication, network segmentation
Tampering: Can an attacker modify SQL queries? → Parameterized queries, ORM
Information Disclosure: Can an attacker read database traffic? → Encryption in transit, network segmentation
Denial of Service: Can an attacker run expensive queries? → Query timeouts, resource quotas
Elevation of Privilege: Can the app server's DB account access unauthorized tables? → Least privilege DB accounts

Prioritizing Threats with DREAD

Once you have enumerated threats, you need to prioritize them. DREAD is a scoring model that rates each threat on five dimensions:

Damage: How bad is the impact if the threat is exploited?
Reproducibility: How reliably can the threat be exploited?
Exploitability: How easy is it to exploit (skill level, tools required)?
Affected Users: How many users are impacted?
Discoverability: How easy is it for an attacker to discover the vulnerability?

Each dimension is scored 1-10. The average is the threat's priority score. A threat scoring 8.5 is more urgent than one scoring 3.2.

DREAD has known weaknesses — it is subjective and different assessors may score the same threat differently. But it provides a consistent framework for comparison and forces you to think about each threat's characteristics rather than relying on gut feeling.

When to Threat Model

Threat modeling is not a one-time activity. You should create or update a threat model:

During design: Before code is written. This is when changes are cheapest.
When architecture changes: A new service, a new data flow, a new trust boundary.
When trust boundaries change: Moving from on-premises to cloud, adding a third-party integration, opening a new API.
After an incident: To understand what threats were missed and why.
Periodically: At least annually for critical systems, or when the threat landscape shifts significantly.

Practice Problems

0 / 2 solved

Solution

Spoofing: An attacker uploads a file with a content-type of image/jpeg but containing malicious HTML/JavaScript. If the server serves it with the wrong content type, it could execute in other users' browsers (stored XSS). Tampering: An attacker modifies the filename parameter in the upload request to overwrite another user's profile picture. Repudiation: The application does not log who uploaded which file, so an attacker can upload illegal content and deny it. Information Disclosure: The upload directory is world-readable, so an attacker can enumerate all uploaded files, including potentially sensitive documents uploaded by other users. Denial of Service: An attacker uploads a 10GB file, exhausting disk space for all users. Elevation of Privilege: An attacker uploads a .php file and executes it on the server, gaining code execution. The fixes: validate file content (not just extension), use random filenames, store uploads outside the web root, implement access controls on the upload directory, set file size limits, and log all upload events.

Solution

DFD: [Browser] --(HTTPS)--> [Web Server] --(SQL over internal network)--> [Database]. Trust boundaries: (1) Browser → Web Server (internet to perimeter), (2) Web Server → Database (application to data layer). The web server → database boundary is most critical because: (a) the database contains the most sensitive data — if this boundary is breached, the attacker has direct access to all data; (b) the web server is the most exposed component — it faces the internet and is the most likely to be compromised; (c) if an attacker compromises the web server and the database connection uses excessive privileges, the attacker can read, modify, or delete all data. Controls: the database connection should use a least-privilege account, the database should not be directly accessible from the web server's network segment, all queries should be parameterized, and database activity should be monitored.

Flashcards

Question

What does each letter in STRIDE stand for?

Click to reveal answer

Answer

Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.

Question

What STRIDE category does a stolen session cookie fall under?

Click to reveal answer

Answer

Spoofing — the attacker impersonates a legitimate user by using their session token. The system cannot distinguish the attacker from the real user.

Question

What STRIDE category does a missing audit log fall under?

Click to reveal answer

Answer

Repudiation — without logs, a user can deny having performed an action and the system cannot prove otherwise. Non-repudiation requires comprehensive, tamper-evident logging.

Question

What are the four elements of a data flow diagram (DFD)?

Click to reveal answer

Answer

Process (transforms data), Data Store (persists data), Data Flow (moves data), External Entity (interacts with the system from outside).

Question

What is a trust boundary and why is it critical?

Click to reveal answer

Answer

A line on a DFD where the level of trust changes. Critical because every data flow crossing a trust boundary must be validated — missing validation at trust boundaries is where most vulnerabilities exist.

Question

What are the five dimensions of DREAD scoring?

Click to reveal answer

Answer

Damage, Reproducibility, Exploitability, Affected Users, Discoverability. Each scored 1-10; the average is the threat's priority score.

Revision Notes

Key Takeaways

1. STRIDE is exhaustive — every software threat fits into at least one category
2. Each STRIDE category maps to a security property: Spoofing→AuthN, Tampering→Integrity, Repudiation→Non-repudiation, Info Disclosure→Confidentiality, DoS→Availability, EoP→AuthZ
3. Trust boundaries are where data must be validated — missing validation is the most common vulnerability pattern
4. Apply STRIDE to every element of the DFD, not just the obvious ones
5. DREAD provides a consistent framework for prioritizing threats, despite being subjective
6. Threat modeling is most effective during design, when changes are cheapest

Interview Tips

• Walk through a concrete threat model you have created — interviewers want to see the process, not just the framework
• Be ready to apply STRIDE to a novel scenario on the spot — this is a common interview exercise
• Discuss how you prioritize threats — DREAD is one approach, but be ready to discuss its limitations
• Explain why trust boundaries are more important than individual components in a DFD
• Connect threat modeling to business outcomes: threats identified during design are 10x cheaper to fix than in production

Cheat Sheet