iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

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

Discussion

Loading…