Threat Modeling — Find the Bugs on the Whiteboard

If you remember nothing else, remember those four questions. The frameworks below are tools that help you answer them.

Use a Data-Flow Diagram (DFD). Five primitives is enough:

• External entities — users, third-party services. Things you don't control.
• Processes — your code: API server, worker, frontend.
• Data stores — databases, caches, queues, S3 buckets.
• Data flows — arrows showing what data moves where.
• Trust boundaries — dotted lines wherever the level of trust changes (internet ↔ your VPC, your VPC ↔ DB subnet, your service ↔ a vendor API).

Most interesting threats live on the trust boundaries. Mark them clearly.

For every element in the diagram, walk the six STRIDE categories. Microsoft's mnemonic, still the best general-purpose checklist.

Letter	Threat	Defends	Example
S	Spoofing	Authentication	Attacker forges a session, replays a JWT, impersonates a service.
T	Tampering	Integrity	Modifying data in transit, in storage, or in flight (e.g., bypassing client-side validation).
R	Repudiation	Non-repudiation / Audit	User denies an action; logs are missing or unreliable.
I	Information Disclosure	Confidentiality	IDOR, verbose errors, S3 misconfig, leaky logs.
D	Denial of Service	Availability	Resource exhaustion, billion-laughs XML, slow loris, expensive query oracle.
E	Elevation of Privilege	Authorization	Mass assignment, missing role check, privilege escalation via shared key.

Not every letter applies to every element — but the discipline of asking each one prevents tunnel vision.

Framework	Best for
STRIDE	Default checklist for app teams; simple, well-known.
LINDDUN	Privacy-focused (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance). Use when GDPR-style risks dominate.
PASTA	Process for Attack Simulation & Threat Analysis — heavier, business-risk-driven, suits enterprise.
Attack Trees	Pick a goal ("steal user data"), branch downward through how an attacker would achieve it. Great for high-value flows.
MITRE ATT&CK	Catalog of real-world adversary tactics. Useful for ops/red-team threat modeling more than design-time.
OWASP Threat Dragon / Microsoft Threat Modeling Tool	If you want a tool. Most teams do fine with a whiteboard and a doc.

For each threat you find, pick one:

• Mitigate. Add a control — input validation, rate limit, RBAC check, encryption.
• Eliminate. Redesign the feature so the threat doesn't exist (the strongest mitigation).
• Transfer. Hand the risk to someone better at handling it (use a managed identity provider, not your own).
• Accept. Document the residual risk and who signed off. Real and legitimate — not every theoretical issue is worth fixing.

Track decisions as ADRs. The "why we didn't fix this" record matters as much as the "what we fixed" record.

• New feature design. The highest-leverage moment. One hour with the design doc.
• Architecture changes. New service, new data store, new vendor.
• Trust-boundary changes. Anything that exposes a previously internal surface.
• Periodic review. Annually or after major releases — the system has drifted from last year's diagram.
• After incidents. Update the model with what you learned.

It doesn't need to be heavyweight. A 60-minute "evil brainstorm" with the team beats a 200-page document nobody reads.

System sketch

User → CDN → Redirect API → Cache (Redis) → DB (Postgres). Redirect API also fetches the target URL on creation to extract the page title (preview feature).

Trust boundaries

• Internet ↔ CDN edge.
• CDN ↔ Redirect API (origin).
• Redirect API ↔ Redis & Postgres (private subnet).
• Redirect API ↔ third-party target URL (egress fetch).

STRIDE walk (abridged)

Element	Threat	Mitigation
Create-link API	S — anonymous abuse to mass-create spam links	Rate limit per IP + per anon quota; CAPTCHA over threshold; abuse domain deny-list.
Create-link API	I — preview-fetch makes server-side requests (SSRF)	Resolve hostname; reject private/loopback/link-local; scheme allow-list (http/https); egress proxy with allow-list.
Redirect	T — open-redirect abuse (phishing through your domain)	Show preview interstitial for low-reputation domains; deny-list known phishing/malware sources.
Redirect	D — viral link DDoSing origin	CDN caches 302s; rate limit at edge; circuit breaker on DB; degrade to read-only on overload.
Stats endpoint	E — IDOR: any user reads any link's stats	Ownership check; partial index keyed on owner; Postgres RLS as defense in depth.
Click events	R — disputed clicks (analytics fraud)	Sign click events; correlate IP + UA + timestamp; rate-limit click writes per IP.

Decisions

• Mitigate: rate limit, SSRF defenses, ownership checks, CDN caching, RLS.
• Accept: sophisticated click fraud — out of scope for v1; revisit after launch metrics.
• Transfer: phishing reputation handled via a third-party domain reputation API rather than building our own.

• Time-box it. 60 minutes per feature, 2 hours for a big architecture change.
• Small group. 2–4 people: an engineer who knows the design, an engineer who likes breaking things, optionally security and ops.
• Adversarial mindset. Pretend you're the attacker. "If I owned that key, what could I do?"
• One page of output. Diagram + STRIDE table + decisions + owners. If it's longer, nobody re-reads it.
• Treat it as a living doc. Update on architecture changes; don't let it bit-rot.
• Don't aim for "all threats found". Aim for the high-impact ones that the team can act on this sprint.