Threat Modeling

Security is a property of the whole system under an adversary's choosing, not a feature you add. Model the attacker's goals and capabilities, then find the cheapest path to them — because that's the path they'll take.

Four questions, in order

1. What are we building? Draw the data flow: components, data stores, and the trust boundaries they cross (user→app, app→DB, service→service, tenant→tenant). Threats live on boundaries.
2. What can go wrong? Walk each boundary with STRIDE: Spoofing (identity), Tampering (integrity), Repudiation (deniability), Information disclosure (confidentiality), Denial of service (availability), Elevation of privilege (authorization).
3. What are we going to do about it? Mitigate, accept (with sign-off), transfer, or eliminate. Not every threat warrants a control.
4. Did we do it right? Validate the mitigations actually hold against a motivated attacker.

Define the attacker before the defenses

• Who: unauthenticated internet, authenticated user, malicious insider, compromised dependency, another tenant. Each has different access and changes the model entirely.
• Capability and motivation: opportunistic script vs targeted adversary vs nation-state. Don't defend against the wrong tier.
• Assets and goals: what does the attacker want (data, money, disruption, foothold)? Rank by impact × likelihood, and protect the crown jewels first.

Adversarial validation (think like the attacker)

• Trace the highest-value asset backward: from the data an attacker wants, what's the shortest chain of trust to reach it? That chain is your priority.
• Assume one layer is breached: the WAF is bypassed, one service is popped, one credential leaks. Does it cascade to total compromise, or does defense-in-depth contain it?
• Attack the trust assumptions: "internal traffic is trusted", "the client validates this", "this field is always well-formed" — every assumption is an attack surface.
• Abuse the features, don't just find bugs: password reset, sharing links, export, impersonation, and rate-limit-free endpoints are designed functionality that becomes an attack tool.
• Confused deputy: can a low-privilege actor trick a high-privilege component into acting on its behalf (SSRF, IDOR, signed-URL reuse)?

Non-obvious risks

• Client-side controls (validation, hidden fields, disabled buttons) are UX, not security — the attacker controls the client entirely.
• The most damaging breaches chain low-severity issues; a "minor" info leak + a "minor" CSRF can compose into account takeover.
• Trust boundaries are often invisible in the code (a microservice that trusts its caller's auth header without re-verifying).

Output structure

Deliver: the data-flow diagram with trust boundaries marked, the attacker profiles in scope, the STRIDE threats per boundary ranked by impact × likelihood, the highest-value-asset attack path traced, the mitigations (or explicit accept-with-rationale), and the "assume-breach" containment check.