Threat Modelling with STRIDE

Four questions

Threat modelling is structured thinking about what can go wrong before you build. A popular framing asks four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good job? Start with a data-flow diagram: external entities (users, third-party APIs), processes (your services), data stores (databases, buckets) and the flows between them. Then draw trust boundaries, the lines where data crosses from less trusted to more trusted zones, such as the internet to your API or your API to the database. Most threats cluster at those boundaries. For each element, walk through STRIDE: Spoofing identity, Tampering with data, Repudiation (denying an action with no proof), Information disclosure, Denial of service and Elevation of privilege. Each threat gets a mitigation, an owner or an explicit decision to accept the risk.

Where threats live

A request travels from the user across the internet trust boundary into the API, then across a second boundary into the database. STRIDE questions are asked at each crossing.

A STRIDE checklist as code

A tiny script that pairs each STRIDE category with the property it violates. Teams often keep such lists next to the design doc so reviews are repeatable.

stride = {
    "Spoofing": "authentication",
    "Tampering": "integrity",
    "Repudiation": "non-repudiation",
    "Information disclosure": "confidentiality",
    "Denial of service": "availability",
    "Elevation of privilege": "authorization",
}
element = "POST /login (internet -> API)"
for threat, prop in stride.items():
    print(f"{element} | {threat:<23} | protect {prop}")

Output:

POST /login (internet -> API) | Spoofing                | protect authentication
POST /login (internet -> API) | Tampering               | protect integrity
POST /login (internet -> API) | Repudiation             | protect non-repudiation
POST /login (internet -> API) | Information disclosure  | protect confidentiality
POST /login (internet -> API) | Denial of service       | protect availability
POST /login (internet -> API) | Elevation of privilege  | protect authorization

Keep it lightweight

A whiteboard photo and a list of ten threats, revisited when the design changes, beats a perfect model nobody updates. Threat model new features in the design review, not after launch.

Quick check: An attacker modifies a price field in a request so they pay less. Which STRIDE category is this?

• Tampering
• Spoofing
• Repudiation
• Denial of service