Threat Modelling
Threat modelling is the structured exercise of asking “what could go wrong?” before it does. STRIDE is the most-used taxonomy. The output is a list of threats with mitigations — not a one-off doc.
STRIDE walkthrough on a checkout flow
EXAMPLE
# Threat model: Checkout API # Scope: customer adds items, submits payment, receives confirmation. # Assets # - Payment data (card / token) # - Order data (PII: name, address) # - Authentication tokens # - Inventory + pricing logic # Trust boundaries # 1. Browser → CDN/edge # 2. CDN → app server (TLS, mTLS) # 3. App → payment provider # 4. App → database # 5. App → message queue (order fulfilment) # STRIDE — for each component / data flow across a trust boundary, ask: # S — Spoofing # T: An attacker submits a request impersonating another user # M: Auth tokens, signed cookies, mTLS between services, IP allowlists on internal endpoints # T — Tampering # T: Attacker modifies cart total / price in transit # M: Server computes price from authoritative product table; never trust client price. # Signed HMAC over critical fields, TLS, DB constraints (CHECK total >= 0). # R — Repudiation # T: User claims they didn't place the order # M: Immutable audit log with user, IP, UA, timestamp, signed; payment provider receipt linkage # I — Information disclosure # T: Order receipts viewable by URL with a guessable ID # M: UUIDs over auto-incrementing IDs; authorisation checks on every read; rate limits # T: Stack traces leak DB schema # M: Disable verbose errors in prod; central error handler returns opaque IDs # D — Denial of service # T: Submit thousands of empty carts to exhaust DB connections # M: Per-IP + per-user rate limits, request body size limits, queue + dead-letter for fulfilment # T: Inventory lock-up — adding 999999 to cart reserves stock # M: Stock reservation TTLs, sanity bounds on quantity, captcha on suspicious sessions # E — Elevation of privilege # T: Customer becomes admin via mass-assignment in /api/profile # M: Allowlist editable fields; serialise input through a Pydantic / Zod / DTO; deny by default # T: SQL injection in product search # M: Parameterised queries, ORM, schema-validated input, WAF for defence-in-depth # Output of the exercise — a backlog of issues, owners, due dates # 1. [P0] Compute order total server-side (currently trusts client) — backend — Sprint 24 # 2. [P1] Add per-IP rate limit to /checkout — platform — Sprint 25 # 3. [P1] Replace incremental order IDs with UUIDs in URLs — backend — Sprint 25 # 4. [P2] Switch to mTLS between app and payment provider — sre — Q3 # Tools # - Microsoft Threat Modelling Tool (free, Windows) # - OWASP Threat Dragon (web, open-source) # - pytm (Python DSL for threat models) # - Lightweight: a Whimsical/Excalidraw diagram + a Google Doc per quarter # Make it part of the SDLC # - New service? Threat model before launch (1-2 hour workshop) # - Significant change? Update existing model (15 min) # - Pen-test findings? Feed them BACK as new threats / mitigations
Why it matters
Threat modelling isn’t a one-off audit — it’s a habit. Even 30 minutes per new endpoint catches design-time bugs that would cost 100x to fix after launch. STRIDE gives juniors a structured way to spot what experts spot by intuition.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
// STRIDE: Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation. // Cycle once per feature: 1) draw data flow, // 2) ask STRIDE per arrow, 3) write mitigations + tests.Try it Yourself »
Exercise
STRIDE's "S" stands for…
, Tampering, Repudiation, Info disclosure, DoS, Elevation
Eight letters.
Discussion
Loading…