29. OWASP Top 10 Web Vulnerabilities
29.9 Threat Modelling (STRIDE)
Example first. Microsoft built STRIDE in the late 1990s and now uses threat modelling in its Security Development Lifecycle. The idea is simple: before you build a feature, sit down and ask "how could someone attack this?" It is far cheaper to fix a design flaw on paper than after launch.
Why it matters
Most security work finds bugs after the code is written. Threat modelling finds weak points in the design, earlier and cheaper. It also makes sure you have not forgotten a whole class of attack.
What it is
Threat modelling means looking at a design and listing how it could be attacked, then planning defences. STRIDE is a checklist of six threat types, one per letter, so you do not miss one.
| Letter | Threat | Plain meaning |
|---|---|---|
| S | Spoofing | Pretending to be someone else |
| T | Tampering | Changing data that should not change |
| R | Repudiation | Doing something, then denying it, with no proof |
| I | Information disclosure | Leaking data to the wrong people |
| D | Denial of service | Making the system unavailable |
| E | Elevation of privilege | Getting more power than allowed |
| STRIDE threat | Common defence |
|---|---|
| Spoofing | Strong login, MFA |
| Tampering | Input checks, hashes, signatures |
| Repudiation | Good logs you cannot edit |
| Information disclosure | Encryption, access control |
| Denial of service | Rate limits, extra capacity |
| Elevation of privilege | Least privilege, server-side checks |
How to do it
- Draw the design: users, servers, databases and the data flow between them.
- Go through STRIDE for each part and each flow.
- Write down each threat you find.
- Pick a defence for each one.
- Rank by risk (Chapter 50.2) and fix the highest first.
- Repeat when the design changes.
Worked examples
Worked example 1: A login page (simplest)
- Spoofing: someone guesses a password. Defence: MFA and lockout.
- Information disclosure: password sent in plain text. Defence: HTTPS and hashing.
- Denial of service: many login tries flood the server. Defence: rate limits.
Worked example 2: A file upload
- Tampering: a user uploads a script, not an image. Defence: check file type on the server.
- Elevation of privilege: the script runs as the web user. Defence: store uploads outside the web folder, no execute.
Worked example 3: An online order view
- Elevation / disclosure: a user changes the order ID and sees another order (IDOR, Chapter 29.5). Defence: check ownership on the server.
- Repudiation: a user denies placing an order. Defence: keep clear, tamper-proof logs.
Real incident: Log4Shell and the value of thinking about inputs (2021)
1. What happened
In December 2021, a bug in the common Log4j logging library (Log4Shell) let attackers run code just by sending a crafted text string that got logged.
2. The STRIDE view
- This is Tampering and Elevation of privilege: untrusted input turned into commands.
- A threat model asks "what if this input is hostile?" for every input, including logs.
3. Lesson
- Treat all input as untrusted, even log messages.
- Think about threats at design time, not only after a bug is public.
In short
- Threat modelling finds design weaknesses before coding.
- STRIDE is a six-point checklist so you miss no threat type.
- For each part of the design, go through all six letters.
- Pick a defence for each threat and fix the highest risk first.