Security · Lesson 10

Threat modeling with STRIDE

Security reviews that happen after shipping find the same things every time — because attackers follow patterns. STRIDE is a forcing function that names those patterns before you write line one, so you spend engineering effort on the right locks.

What threat modeling actually is

A threat model is a structured conversation about what could go wrong — before a system is fully built. It does not require formal tools or security specialists. It requires one discipline: look at your own system the way an attacker would, and do it while you still have room to change things.

The output is not a document. The output is a list of threats, each with an owner and a mitigation decision: fix it, accept it, transfer it (e.g. to your cloud provider), or acknowledge the residual risk. Anything without a decision is just anxiety.

Think of it like a fire drill run before the building is occupied. No one has been hurt yet, but you walk every exit to confirm it opens. If a door is jammed, you fix the door — not the evacuation plan.

Trust boundaries and data-flow thinking

Before naming threats, you need a map of your system from the attacker's perspective. The key concept is the trust boundary: a line in your architecture where data crosses from a context you control to one you don't — or from one trust level to another.

Common trust boundaries in an API:

• The public internet → your load balancer (untrusted to perimeter)
• Your load balancer → your application server (perimeter to app tier)
• Your application server → your database (app tier to data tier)
• Your app → a third-party payment processor (your system to external system)
• An anonymous user → an authenticated user (privilege boundary)

Every time data crosses a boundary, ask: can an attacker influence what crosses, intercept it, or replay it? That question, run for each boundary, surfaces the threats STRIDE will name.

STRIDE: six threat categories, six questions

STRIDE was developed at Microsoft in 1999 and remains the most practical mnemonic for API threats because each letter maps directly to a property your system needs to preserve — and an attack class that violates it.

Worked example: STRIDE on POST /transfers

Take a single endpoint — POST /transfers in a payments API — and run STRIDE systematically. This is what a real threat-modeling session produces, in condensed form:

# Endpoint: POST /transfers
# Request body: { "from": "acc_1", "to": "acc_2", "amount_cents": 5000 }
# Trust boundary crossed: public internet → app tier (TB-1)

──────────────────────────────────────────────────────────────────
 STRIDE    Threat                              Mitigation
──────────────────────────────────────────────────────────────────
 Spoofing  Stolen Bearer token reused after   Short expiry (15 min) +
           the legitimate user logs out.       denylist on logout. (sec-08)

 Tamper    Body intercepted; "to" changed     TLS 1.3 + HSTS preload
           to attacker account in transit.     on all environments. (sec-02)

 Repudia   User denies authorising transfer;  Append-only ledger row: actor,
           no log to contradict them.          timestamp, IP, signed request.

 Info disc  DB constraint error bubbles up:   Catch all DB exceptions; return
           "duplicate key: transactions(id)"  generic 500 with trace-id only.
           — reveals schema detail.            Log full error internally. (sec-03)

 DoS       Attacker hammers endpoint until     Per-user rate limit: 10 req/min.
           DB pool exhausted for others.       Global limit: 1000 req/min.
                                               Circuit breaker on DB pool.

 Elevate   User forges "from":"acc_admin"      Server validates that JWT sub
           to transfer from another user's     matches the "from" account owner
           account.                            before processing. (sec-05)
──────────────────────────────────────────────────────────────────

When and how to run it

The highest-leverage time is during design — before any code is written. A 90-minute whiteboard session with the feature author, a backend engineer, and one person playing devil's advocate covers most surfaces for a new endpoint. Run it again whenever the trust-boundary map changes: new external integration, new user role, new data sensitivity level.

1. Draw the data-flow diagram. Boxes for processes and data stores, arrows for data flows, dashed lines for trust boundaries. Five minutes on a whiteboard. If you can't draw it, you don't understand the system yet.
2. List the elements at each trust boundary. For each arrow that crosses a dashed line: what data, from whom, to whom.
3. Run STRIDE per element. For each data flow, ask all six questions. Not all six will apply — that's fine. Write down the ones that do and their mitigations.
4. Decide on each threat. Fix, accept (with explicit rationale), transfer (cloud provider handles TLS), or flag for later. Any threat without a decision is unfinished work.
5. Track it. A threat model that lives only in a meeting is dead by Thursday. A two-column table (threat → decision) in the design doc survives code reviews and onboarding.

Under the hood: how it actually works

Reading about STRIDE is not the same as running a session. This section shows you the mechanics of an actual 90-minute threat modeling meeting, then traces a complete worked example at a level of detail that lets you run one yourself.

Running a STRIDE session: the four artifacts you produce

1. Data-flow diagram (DFD). Draw boxes (processes and data stores) connected by labeled arrows (data flows). Mark every dashed boundary line where trust changes. Rule: if you cannot draw it, you do not understand the system. This takes 10–15 minutes and surfaces architecture you hadn't articulated yet.
2. Element inventory. List every arrow that crosses a trust boundary. For each: what data type, from whom, to whom, is it authenticated, is it encrypted in transit.
3. STRIDE threat table. For each element in the inventory, run the six questions. Write every threat as a concrete attacker action ("attacker replays captured token within 15-minute window") not a vague category ("token reuse"). Assign a severity: High / Medium / Low.
4. Decision register. For every threat: Fix, Accept, Transfer, Defer — with an owner and due date. This is the only artifact that must survive the meeting.

Fully worked threat model: POST /transfers

The endpoint accepts a money transfer request from an authenticated user. Trust boundary crossed: TB-1 (untrusted internet → app tier). Here is every STRIDE threat enumerated with the concrete attack and chosen mitigation:

How the DFD maps to the threat table

Every row in the table above corresponds to a specific arrow crossing TB-1 in the data-flow diagram. The discipline is: for each crossing arrow, you ask all six STRIDE questions. If you skip an arrow, you get a blind spot. The worked example above focuses on the single arrow "Client app → API Gateway / Transfer service." In a full session you would repeat the exercise for every arrow in the diagram — including internal ones like "Transfer service → Accounts DB" (where SQL injection, direct DB access without auth, and connection pool exhaustion live).

How to debug & inspect it

Threat modeling findings need to become tests and monitoring, otherwise they evaporate after the meeting. This section shows how to operationalize each STRIDE category so you can verify mitigations are actually working.

Turn each of the above into a test in your integration/contract test suite so regressions are caught before they ship.

Threat model review checklist:

1. Is there a DFD with labeled trust boundaries? If you can't point to TB-1, TB-2, etc. in a diagram, the session is incomplete.
2. Has every arrow crossing a trust boundary been enumerated in the threat table?
3. Does every threat have a decision (Fix / Accept / Transfer / Defer) with an owner?
4. Are "Accept" decisions accompanied by explicit rationale — not just "low priority"?
5. Is there a test or monitoring signal for every "Fix" decision?
6. Is the threat model in source control (or linked from the design doc) so it survives onboarding?
7. Has a review been scheduled for the next time the trust boundary map changes?

Spoofing:       Attacker triggers reset for a victim's account, then
                intercepts the link (e.g. open-redirect, email forwarding).
  Mitigation:   Reset tokens are single-use, short-lived (15 min), and
                bound to the requesting IP. Invalidate on use.

Tampering:      Link in email contains user ID in plain text;
                attacker edits it to target another account.
  Mitigation:   Token is opaque and random (not the user ID). Map token →
                user server-side. Never embed identity in the token.

Repudiation:    User claims they never requested a reset; attacker
                used it to lock them out.
  Mitigation:   Log: requester IP, timestamp, account, whether link was
                used. Notify account owner by email on request AND on use.

Info disclosure: Endpoint returns different response for existing vs.
                non-existing email → attacker enumerates user accounts.
  Mitigation:   Always return the same 200 response ("if an account
                exists, you'll receive an email"). Never distinguish.

DoS:            Attacker floods with 10 000 different emails, spamming
                users and exhausting the transactional email quota.
  Mitigation:   Rate-limit per IP: 3 req/min. CAPTCHA for anonymous
                callers. Per-account cooldown: 1 reset request per 5 min.

Elevation:      Accepted — this endpoint is unauthenticated by design;
                it cannot elevate privilege because the reset token grants
                only the ability to set a new password for one account,
                verified via the signed token. No admin paths involved.

Sources & further reading

• Microsoft — STRIDE threat categories — the canonical Microsoft documentation for STRIDE
• Microsoft — Threat Modeling — practical process guidance
• OWASP — Threat Modeling Cheat Sheet — process, tools, and worked examples
• OWASP — Threat Modeling Process — data-flow diagrams and trust boundaries in detail
• Adam Shostack — Threat Modeling: Designing for Security — the practitioner's reference book (O'Reilly)