Threat Modeling (Practical, Repeatable)

Goal

Create a repeatable threat modeling loop that produces concrete actions: config changes, logging/alerting, test cases, and runbooks. Keep it small enough to run per feature.

Minimum Data You Need

• Assets: user identities, sessions/tokens, payment actions, PII fields, admin actions.
• Entry points: HTTP routes, webhooks, upload endpoints, background jobs.
• Trust boundaries: browser → edge → app → internal services → data stores.
• Dependencies: IdP, email/SMS, object storage, third-party APIs.

Production Workflow (30–60 minutes)

1. Pick a single feature or endpoint group (example: /api/payments/*).
2. List top 5 abuse cases (auth bypass, replay, enumeration, injection, data exfil).
3. For each abuse case, define: preconditions, detection, mitigation, runbook owner.
4. Turn mitigations into checklists (headers, limits, validation, rate limiting, logging).

Abuse Case Template

Abuse case:
- What: (ex) Attacker replays webhook to credit account twice
- Preconditions: webhook endpoint accepts duplicates; no idempotency
- Detection: log event_id + status; alert on duplicates
- Mitigation: idempotency key; store processed event_ids; reject replays
- Runbook: disable webhook, rotate secret, reconcile transactions

Controls Mapping (Operator Lens)

• Prevent: authZ checks, validation, idempotency, allowlists, mTLS.
• Detect: structured logs, auth anomalies, spike alerts, WAF signals.
• Respond: kill switches, token revocation, key rotation, incident steps.

Make It Measurable

• Log security-relevant fields (request id, user id, auth method, decision, reason).
• Define 3 alerts: auth failures spike, forbidden spike, sensitive action spike.

Quick Checks

# Identify trust boundaries and exposed surfaces
curl -sS -D - https://app.example.com/healthz -o /dev/null

# Enumerate routes (example pattern; adapt to your router)
grep -R "GET /api" -n ./src | head -50