Feature Threat Modeling Review Workflow

Model the abuse cases for a new feature before building it: assets, entry points, trust boundaries, and the mitigations the design must include.

intermediate~35 minsecurity-auditthreat-modelingdesign

Objective

Surface security requirements as design inputs rather than post-launch patches, by walking the abuse cases at review time.

Environment

A feature design document or PRD
The system's trust-boundary map
A review slot with security-literate participants

Steps

1. Enumerate assets and entry points

List what the feature touches that an attacker wants (data, money, quota, availability) and every way it accepts input (API, upload, webhook, URL param).

Expected state: An asset and entry-point list exists for the feature.

2. Walk the trust boundaries

Trace each entry point across boundaries (client to server, service to service, user to admin), asking what crosses and what validates it.

Expected state: Every crossing is named with its validation or marked missing.

3. Brainstorm abuse cases per entry

For each entry point, ask how it is abused: replay, enumeration, injection, privilege confusion, resource exhaustion, and confused deputy.

Expected state: Abuse cases exist per entry point, ranked by asset damage.

4. Convert to design requirements

Turn each credible abuse case into a concrete design requirement (rate limit, idempotency key, authorization check, input validation) tracked like functional requirements.

Expected state: The design doc carries security requirements with acceptance criteria.

5. Verify mitigations at review

At design and code review, verify each requirement is implemented and testable, rejecting clever-but-unmitigated paths.

Expected state: The shipped feature maps every abuse case to a verified mitigation or an accepted residual risk.

Expected outcome

Features whose abuse cases were modeled before construction, with security requirements implemented and verified rather than discovered in an incident.

Verification

The feature's test plan covers each abuse case; the design doc's security requirements all trace to code and tests; post-launch incidents in this feature class trend to zero.

Abuse cases are requirements in disguise

Asking how will people misuse this at design time converts security from a post-launch patch discipline into design input. The walk is short — assets, entries, boundaries, abuse — and each credible abuse case becomes a tracked requirement.

feature: gift-code redemption
assets:   promo budget, code exhaustion, account takeover?
entries:  POST /redeem {code}, code entry rate
boundaries: client->server, anon->authed, api->ledger

abuse cases:
  brute-force codes (enumeration)
    -> req: rate limit 5/h + lockout + code entropy 2^40
  replay redemption (double spend)
    -> req: idempotency key per account+code
  transfer codes between accounts (enumeration via
    error difference)
    -> req: uniform error, no code validity leak
  ledger race (concurrent redeem)
    -> req: atomic decrement (transactional)

verified: 4/4 mitigations in tests; residual: none

Enumeration hides in error messages

The most common feature-level flaw is informational asymmetry: invalid code returns a different error than expired code, so attackers enumerate the valid space. Walking abuse cases surfaces this at design time, where the fix (uniform errors) costs one line instead of an incident retro.

Requirements, not suggestions

A threat model that lists risks without converting them into tracked requirements gets admired and ignored. Each credible abuse case must land in the design doc with acceptance criteria, so review verifies a mitigation exists — the same treatment functional requirements get.