threat-model

When to use

• Designing a new feature, endpoint, or service before it is built.
• A change introduces a new trust boundary: user input, third-party API, file upload, auth flow, payment, or PII.
• The user asks "how could an attacker abuse this?" or wants a security design review on a one-page budget.

Process

1. Scope it. One feature/flow at a time. Get the data flow: actors → entry points → components → data stores → external services.
2. List assets worth protecting — credentials, PII, money, tokens, the integrity of records, availability of the service.
3. Draw trust boundaries — where data crosses from less-trusted to more-trusted (browser→API, service→DB, your code→third party). Threats live at these boundaries.
4. Walk STRIDE at each boundary (table below). For each applicable threat, write one concrete attack and one concrete mitigation.
5. Rank the threats by rough likelihood × impact and mark which mitigations are must-do-before-ship vs. follow-up.
6. Output one page — no novel, just the table plus the top risks.

What to check — STRIDE

• Spoofing (identity) — can someone pretend to be another user/service? → strong authn, signed tokens, mTLS.
• Tampering (integrity) — can data/requests be modified in transit or at rest? → integrity checks, input validation, parameterized queries, signed/immutable records.
• Repudiation — can an actor deny an action? → audit logs, signed/append-only trails.
• Information disclosure (confidentiality) — can data leak? → encryption in transit/at rest, least-privilege, scrubbed errors/logs, no secrets in responses.
• Denial of service (availability) — can it be exhausted/crashed? → rate limits, quotas, timeouts, payload size caps, pagination.
• Elevation of privilege (authorization) — can a user do more than allowed? → per-object authz checks, deny-by-default, no trusting client-supplied roles/IDs.

How to fix

• Pair every accepted threat with a specific, assignable mitigation (control + where it lives), not a vague "validate input".
• Prefer platform/framework controls over hand-rolled ones (the framework's authz, the cloud's KMS, the gateway's rate limiter).
• For threats you accept without mitigating, record an explicit risk-acceptance note so it is a decision, not an oversight.

Report back

Deliver a one-page model: a short data-flow description, the asset list, and a STRIDE table (threat → attack scenario → mitigation → priority). Close with the top 3 risks to address before shipping and any explicitly accepted residual risks.