Security Threat Modeling

Start with the decision#

Model valuable assets, actors, data flows, and trust boundaries before choosing controls; each credible abuse path needs an explicit response and a testable requirement.

Mechanism and state flow#

Scope the system and name sensitive assets.
Draw actors, processes, stores, data flows, and trust boundaries.
Walk abuse cases such as spoofing, tampering, disclosure, denial, and privilege escalation.
Rank likelihood and impact, then mitigate, eliminate, transfer, or explicitly accept each threat.
Validate controls and update the model when architecture or exposure changes.

Trust-boundary threat model

An untrusted client crosses an authenticated API boundary before private data and an external provider, exposing concrete abuse paths.

Concrete example#

Worked example

File-sharing link

Assets include private files and access grants. Actors include owners, invited users, anonymous link holders, and support staff. The share-token boundary exposes guessing, replay, leakage through logs, and overbroad revocation.

Architecture consequence: Controls become concrete: high-entropy tokens, scoped grants, expiry, redacted logs, owner-visible audit, rate limits, and tested revocation.

Trade-offs#

Option	Choose when	Cost or limit
Capability link	Low-friction delegated access is a requirement.	Possession grants authority, so leakage and revocation matter.
Account membership	Identity, audit, and durable revocation dominate.	Higher onboarding and recovery friction.
Network boundary	A service is genuinely internal and network identity is controlled.	Network location alone is not user authorization.

Failure diagnosis#

Failure deep dive

Failure: The diagram omits an administrative or asynchronous path.
Impact: A privileged or replayable flow escapes the reviewed controls.
Detection: Runtime inventory, logs, and data-flow review reveal actors or writes absent from the model.
Mitigation: Treat undocumented boundaries as findings, enumerate background and support actors, and bind mitigations to executable acceptance tests.
Trade-off: Maintaining the model costs review time but exposes assumptions before they become incidents.

Design checkpoint#

Work the scenario before revealing the checklist

List three assets and why an attacker values each.
Mark every trust boundary and privileged actor.
Write one abuse path for identity, integrity, confidentiality, and availability.
Turn each chosen mitigation into a testable requirement.

Interviewer follow-ups

Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.

What changes when support staff can impersonate a user?
Where can secrets or personal data enter logs?
Which accepted threat needs an explicit owner and review date?

Apply the lesson

Start with the decision#

Model valuable assets, actors, data flows, and trust boundaries before choosing controls; each credible abuse path needs an explicit response and a testable requirement.

Mechanism and state flow#

Scope the system and name sensitive assets.
Draw actors, processes, stores, data flows, and trust boundaries.
Walk abuse cases such as spoofing, tampering, disclosure, denial, and privilege escalation.
Rank likelihood and impact, then mitigate, eliminate, transfer, or explicitly accept each threat.
Validate controls and update the model when architecture or exposure changes.

Trust-boundary threat model

An untrusted client crosses an authenticated API boundary before private data and an external provider, exposing concrete abuse paths.

Concrete example#

Worked example

File-sharing link

Architecture consequence: Controls become concrete: high-entropy tokens, scoped grants, expiry, redacted logs, owner-visible audit, rate limits, and tested revocation.

Trade-offs#

Option	Choose when	Cost or limit
Capability link	Low-friction delegated access is a requirement.	Possession grants authority, so leakage and revocation matter.
Account membership	Identity, audit, and durable revocation dominate.	Higher onboarding and recovery friction.
Network boundary	A service is genuinely internal and network identity is controlled.	Network location alone is not user authorization.

Failure diagnosis#

Failure deep dive

Failure: The diagram omits an administrative or asynchronous path.
Impact: A privileged or replayable flow escapes the reviewed controls.
Detection: Runtime inventory, logs, and data-flow review reveal actors or writes absent from the model.
Mitigation: Treat undocumented boundaries as findings, enumerate background and support actors, and bind mitigations to executable acceptance tests.
Trade-off: Maintaining the model costs review time but exposes assumptions before they become incidents.

Design checkpoint#

Work the scenario before revealing the checklist

List three assets and why an attacker values each.
Mark every trust boundary and privileged actor.
Write one abuse path for identity, integrity, confidentiality, and availability.
Turn each chosen mitigation into a testable requirement.

Interviewer follow-ups

Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.

What changes when support staff can impersonate a user?
Where can secrets or personal data enter logs?
Which accepted threat needs an explicit owner and review date?

Apply the lesson

What you will learn

Start with the decision#

Mechanism and state flow#

Concrete example#

File-sharing link

Trade-offs#

Failure diagnosis#

Design checkpoint#

Related practice problems

Finish this lesson

Security Threat Modeling

What you will learn

Start with the decision#

Mechanism and state flow#

Concrete example#

File-sharing link

Trade-offs#

Failure diagnosis#

Design checkpoint#

Related practice problems

Finish this lesson