Threat modeling
A threat model is the cheapest security work you will ever do: it costs a
whiteboard and an hour, and it moves defenses into the design where they are
free instead of into production where they are expensive. Skip it and you
find the gaps after an attacker does.
Method
- Inventory the assets worth stealing. List what an attacker wants:
credentials, session tokens, payment data, PII, admin capabilities, the
database itself. Rank them by what a breach of each would cost.
Everything downstream defends this list.
- Draw the data flow with trust boundaries. Sketch the browsers, your
services, the database, third-party APIs, and queues. Draw a line
wherever data crosses from less-trusted to more-trusted (internet to
server, service to database). Each line is where you spend attention.
- Enumerate entry points. Every route, form field, file upload,
webhook, queue consumer, CLI flag, and env var is a door. Write them all
down; the one you forget is the one that ships unguarded.
- Walk STRIDE against each boundary. Ask the six per crossing:
Spoofing (fake an identity?), Tampering (alter data in transit or at
rest?), Repudiation (deny an action with no audit trail?), Information
disclosure (read what they should not?), Denial of service (exhaust a
resource?), Elevation of privilege (become admin?). Name a concrete
threat for each letter that applies.
- Rate the threats and assign mitigations. Score each by likelihood
times impact (DREAD, or a plain high/medium/low). For the top ones pick
a control: parameterized queries, an authz check, rate limits, signed
tokens. Document low-risk items as accepted, not silently dropped.
- Write the model down and revisit it. Store the diagram and threat
table in the repo next to the code. Re-open it when the feature grows a
new entry point; a stale threat model lies by omission.
Litmus tests
- Can you name the highest-value asset this feature exposes and the control
protecting it?
- Does every entry point on your list map to at least one STRIDE threat you
considered?
- Would a new engineer reading the model understand what you chose not to
defend, and why?
Boundaries
Threat modeling scopes the design; it does not verify the implementation.
Pair it with code-level review and testing to confirm the controls were
built correctly. For high-stakes systems (payments, health data, crypto)
bring in a security specialist rather than trusting a solo walkthrough.
1---2name: threat-modeling3description: Map assets, entry points, and STRIDE threats before writing code so defenses land in the design instead of a later patch. Use when starting a feature that handles auth, money, personal data, or external input.4---56# Threat modeling78A threat model is the cheapest security work you will ever do: it costs a9whiteboard and an hour, and it moves defenses into the design where they are10free instead of into production where they are expensive. Skip it and you11find the gaps after an attacker does.1213## Method14151. **Inventory the assets worth stealing.** List what an attacker wants:16 credentials, session tokens, payment data, PII, admin capabilities, the17 database itself. Rank them by what a breach of each would cost.18 Everything downstream defends this list.192. **Draw the data flow with trust boundaries.** Sketch the browsers, your20 services, the database, third-party APIs, and queues. Draw a line21 wherever data crosses from less-trusted to more-trusted (internet to22 server, service to database). Each line is where you spend attention.233. **Enumerate entry points.** Every route, form field, file upload,24 webhook, queue consumer, CLI flag, and env var is a door. Write them all25 down; the one you forget is the one that ships unguarded.264. **Walk STRIDE against each boundary.** Ask the six per crossing:27 Spoofing (fake an identity?), Tampering (alter data in transit or at28 rest?), Repudiation (deny an action with no audit trail?), Information29 disclosure (read what they should not?), Denial of service (exhaust a30 resource?), Elevation of privilege (become admin?). Name a concrete31 threat for each letter that applies.325. **Rate the threats and assign mitigations.** Score each by likelihood33 times impact (DREAD, or a plain high/medium/low). For the top ones pick34 a control: parameterized queries, an authz check, rate limits, signed35 tokens. Document low-risk items as accepted, not silently dropped.366. **Write the model down and revisit it.** Store the diagram and threat37 table in the repo next to the code. Re-open it when the feature grows a38 new entry point; a stale threat model lies by omission.3940## Litmus tests4142- Can you name the highest-value asset this feature exposes and the control43 protecting it?44- Does every entry point on your list map to at least one STRIDE threat you45 considered?46- Would a new engineer reading the model understand what you chose not to47 defend, and why?4849## Boundaries5051Threat modeling scopes the design; it does not verify the implementation.52Pair it with code-level review and testing to confirm the controls were53built correctly. For high-stakes systems (payments, health data, crypto)54bring in a security specialist rather than trusting a solo walkthrough.
Amey-Thakur