STRIDE Applied to API Security

STRIDE helps architects systematically assess threats across six key areas. By applying STRIDE during the design phase, organisations can identify vulnerabilities before implementation and ensure appropriate controls are in place before a single line of code is committed.
Spoofing: unauthorised access or impersonation of API callers
Tampering: unauthorised modification of request or response data
Repudiation: lack of traceability or accountability for API calls
Information Disclosure: exposure of sensitive data via API responses
Denial of Service: disruption of API availability through abuse
Elevation of Privilege: gaining higher access than intended via API

Effective API Security Controls

Authentication and Authorisation

Strong authentication and authorisation using OAuth 2.0 and JWT tokens ensures that only verified identities can call APIs and that each identity can only access the resources and operations it is entitled to. Scopes should be narrow and specific.

STRIDE Threat Model — Applied to API Security Six threat categories mapped to API attack surfaces with mitigations S — SPOOFING Threat: Impersonation of API callers Surface: Auth endpoints / JWT tokens Mitigation: OAuth 2.0 · MFA · API key rotation Detect: Failed auth spikes · Token replay T — TAMPERING Threat: Modification of request/response Surface: Request body / headers / params Mitigation: Input validation · Request signing Detect: Schema violations · WAF alerts R — REPUDIATION Threat: Untraceable API actions Surface: All API endpoints Mitigation: Signed tokens · Audit logging Detect: Missing correlation IDs · Log gaps I — INFO DISCLOSURE Threat: PII / IP exposed in responses Surface: Error messages / response bodies Mitigation: Response masking · DLP · TLS 1.3 Detect: Data volume anomalies · CASB D — DENIAL OF SERVICE Threat: API abuse / volumetric attack Surface: Public endpoints / auth flows Mitigation: Rate limiting · WAF · AWS Shield Detect: Request rate spikes · 429 errors E — ELEVATION OF PRIV Threat: Gain higher access than permitted Surface: JWT scopes / RBAC misconfig Mitigation: Least privilege · Scope validation Detect: UEBA · Privilege use anomalies API GATEWAY — Central enforcement point for all six STRIDE mitigations OAuth 2.0 / JWT Input validation Audit logging TLS + DLP Rate limiting Least privilege RBAC STRIDE applied at design phase prevents vulnerabilities before implementation · API Gateway enforces all six controls · saleemyousaf.co.uk
// STRIDE threat model applied to API security — six threat categories with mitigations and detection signals

Input Validation and Rate Limiting

All API inputs should be validated for type, length, format, and content before processing. Rate limiting prevents abuse patterns such as credential stuffing, brute force, and volumetric denial of service attacks. Apply limits per client identity, not just per IP address.

Encryption and Data Protection

Encryption of data in transit using TLS 1.2 or higher is non-negotiable. Sensitive data in responses should be masked or redacted where it is not needed by the caller. Internal APIs should not expose more data than the consuming service requires.

Monitoring and Logging

Monitoring and logging of API activity creates the observability layer that STRIDE threat models depend on. Log caller identity, request parameters, response codes, and timing. Forward to SIEM for correlation with other security events.

Security should not be treated as an add-on but as an integral part of system design. A structured, design-led approach ensures APIs remain secure, resilient, and aligned with enterprise security standards.
Back to all articlesDesigning Secure AWS Landing Zones