Threat Modeling

Key Claims

• Threat modeling belongs in design, not in incident response. Reactive security is far more expensive than proactive analysis. Integrate the model into the SDLC; revisit it on every new endpoint, trust-boundary change, or security incident.
• STRIDE classifies threats; DREAD scores them. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege) per element on the Data Flow Diagram; DREAD ranks the surfaced threats. Prefer DREAD-D (drop Discoverability) to avoid rewarding security-through-obscurity.
• The OWASP API Top 10 is the practitioner checklist. BOLA, Broken Auth, Excessive Data Exposure, Lack of Rate Limiting, Broken Function Auth, Mass Assignment, Misconfiguration, Injection, Improper Assets Mgmt, Insufficient Logging. Cover all ten before claiming an API is secure.
• Mass assignment is more insidious than injection. Auto-binding request bodies to domain objects (isAdmin: true) lets attackers set fields they shouldn't control. Explicit allowlisting; never bind directly.
• Rate limiting belongs at the gateway, not the service. Apply before compute resources are consumed. Token bucket is the standard choice — allows legitimate bursts while capping sustained throughput.
• Pie Crust defence is the enterprise antipattern. Authenticate at the perimeter but trust everything internal. Internal services must also authenticate callers; encrypt internal traffic too (Zero Trust).
• Components with known vulnerabilities are the Equifax lesson. Automate CVE checking in CI; treat container images as perishable (rebuild from upstream, don't patch in place).

Definition

Threat modeling is a structured process for identifying, evaluating, and mitigating security threats to a system before they can be exploited. For APIs, it is the practice of systematically analysing the attack surface — the interfaces, data flows, and trust boundaries — and then prioritising defenses based on the severity and likelihood of each threat.

Why It Matters

APIs are externally accessible endpoints that expose internal data and logic. They are among the highest-value attack targets in any system. Reactive security — patching after an incident — is far more costly than proactive modeling. Threat modeling integrates security thinking into the design phase, where changes are cheap, rather than into the incident response phase, where they are not.

OWASP API Security Top 10

The OWASP API Security Top 10 (2019) catalogues the most critical API-specific vulnerabilities (→ Mastering Api Architecture Ch 6):

STRIDE Framework

STRIDE is a threat classification framework developed at Microsoft. Each letter identifies a threat category and a corresponding security property that must be protected (→ Mastering Api Architecture Ch 6):

STRIDE is applied per-element: each node and data flow on the Data Flow Diagram is evaluated against all six threat categories.

The Six-Step Threat Modeling Process

(→ Mastering Api Architecture Ch 6)

Step 1 — Define security objectives: what must be protected, and why. Align with business risk and regulatory requirements (GDPR, PCI-DSS, etc.).

Step 2 — Gather information: map the system's components, trust zones, external interfaces, and data classification levels.

Step 3 — Decompose the system: produce a Data Flow Diagram (DFD) showing:

• Processes (circles)
• Data stores (parallel lines)
• External entities (rectangles)
• Data flows (arrows, labelled with data type and direction)
• Trust boundaries (dashed lines separating zones of different trust)

Step 4 — Identify threats: apply STRIDE to each DFD element systematically. Each external-facing data flow and process is a candidate for every STRIDE category.

Step 5 — Evaluate and prioritise (DREAD): score each identified threat using DREAD:

DREAD score = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5

Threats scoring above a defined threshold (e.g. 7) are treated as high priority.

Step 6 — Validate: verify that mitigations are in place and that the model is reviewed whenever the system changes significantly.

API-Specific Threats

Several OWASP categories deserve particular attention in API threat models:

Payload injection: API parameters passed to databases, shell commands, or templating engines without sanitisation. Mitigation: parameterised queries, input validation at the API gateway, OAS schema validation.

Mass assignment: accepting all fields of a request body and binding them to a domain object — allowing callers to set fields they should not control (e.g. isAdmin: true). Mitigation: explicit allowlisting of writable fields; never bind request bodies directly to domain entities.

Excessive data exposure: returning full internal objects and relying on the client to filter. Mitigation: define explicit response schemas; use GraphQL projections or dedicated read-model DTOs to return only needed fields.

Improper assets management: undocumented or deprecated API versions that are still live and unmonitored. Mitigation: API lifecycle governance (Api Gateway) with enforced deprecation and retirement; single OAS per version.

Rate Limiting Strategies

Rate limiting is the primary mitigation for Denial of Service (STRIDE D) and brute-force attacks (→ Mastering Api Architecture Ch 6):

Token bucket is the most common for API rate limiting because it allows short legitimate bursts (e.g. a mobile app syncing on wake) while capping sustained throughput.

Rate limiting should be enforced at the API gateway layer, not inside individual services, so that it applies uniformly before compute resources are consumed.

Security Hardening at the Gateway

Beyond the logical threat mitigations, several gateway-level hardening controls are worth making explicit (→ Mastering Api Architecture Ch 6):

TLS version enforcement: Always require TLS 1.2 or later. Most commercial gateways default to current versions; weaker versions with known vulnerabilities must be explicitly re-enabled if needed (which should require a documented exception).

CORS configuration: Cross-Origin Request Sharing (CORS) allows browsers to permit cross-origin HTTP requests. A permissive CORS configuration is a common security misconfiguration — it can allow a malicious site to make authenticated requests on behalf of the user. Configure allowed origins precisely.

HTTP header allowlisting: Reject requests with unknown or invalid HTTP headers rather than silently ignoring them. An attacker can include headers like X-Assert-Role: Admin hoping they are forwarded unchecked and used internally to grant elevated privileges.

Trust-but-verify principle: Input validation at the API gateway (e.g. via OAS schema validation) is the first line of defence, not the only line. The backend service must still sanitise inputs and use parameterised queries. If the gateway check fails or is bypassed, the service must not be the last-to-fail.

Friendly Fire DoS

Denial of service attacks do not have to come from malicious actors. As systems evolve, it is possible to accidentally introduce circular dependencies between internal services — Service A calls Service B which calls Service A — creating an infinite request loop under certain conditions. This "friendly fire DoS" can overwhelm both services without any external attacker. Mitigations: rate limiting on internal API calls, circuit breakers (Circuit Breaker), and error monitoring for unexpected internal request spikes.

DREAD and DREAD-D

The standard DREAD risk calculation includes a Discoverability dimension (how easy is the vulnerability to find?). However, including discoverability can reward security through obscurity — implying that a vulnerability is lower risk simply because it is harder to find. DREAD-D (DREAD minus Discoverability) drops this dimension, reducing the formula to:

DREAD-D score = (Damage + Reproducibility + Exploitability + Affected Users) / 4

DREAD-D is preferred when the team wants to avoid the temptation to lower-rank a threat simply because it is not yet publicly known. The Common Vulnerability Scoring System (CVSS) — used by NIST to evaluate CVEs — provides an alternative standardised scoring approach for tracking against public vulnerability databases.

Threat Modeling and the SDLC

Threat modeling is most valuable when integrated into the development lifecycle at the design phase, not as a one-time audit. The model should be revisited:

• When new API endpoints are added
• When trust boundaries change (e.g. an internal API becomes external)
• After any security incident
• On a periodic cadence (e.g. annually for low-change systems)

OWASP Top 10 for Web Applications (Nygard)

Nygard (→ Release It ch. 11) covers the web application OWASP Top 10 (2017 list) with an architectural emphasis. Key points beyond what the API-security list already covers:

• Broken Access Control: never use sequential database IDs in URLs (enables ID enumeration); return identical 404 for "doesn't exist" and "not authorized to see" — never confirm whether a resource exists to unauthorized callers.
• "Pie Crust" defence (antipattern): authenticate at the perimeter but trust all internal calls freely. Internal services must also authenticate callers; encrypt all traffic even on internal networks (→ Zero Trust).
• Components with Known Vulnerabilities: this was the root cause of the Equifax breach (Struts 2 CVE-2017-5638). Automate CVE checking in the CI pipeline; treat container images as perishable (rebuild from upstream base images rather than patching in-place).
• Session Management: fresh session ID on every successful authentication (prevents session fixation); use cryptographically secure PRNGs for session IDs; accept session IDs only from cookies, never URL parameters.

Related Concepts

• Zero Trust — zero trust removes implicit trust from the network model; threat modeling identifies what must be explicitly verified
• Oauth2 And Authn — OAuth2 and JWT are the primary mitigations for STRIDE S (Spoofing) and E (Elevation of Privilege)
• Api Gateway — the gateway is the enforcement point for rate limiting, input validation, and auth at the API perimeter
• Api Design — OAS schema validation at the gateway is a first-line defence against injection and mass assignment
• Adrs — threat model decisions (fail-open vs fail-closed; rate limiting thresholds) should be captured in ADRs