An API becomes vulnerable not because of a single missing header, but because its security contract is weak from the beginning.
The chapter assembles API protection from several layers: identity and authorization checks, rate limiting, schema validation, anti-replay, abuse prevention, and a secure lifecycle for the interface itself.
In architecture discussions, it is a good frame for analyzing the public edge, internal APIs, trust zones, and why interface security begins before the first endpoint is even added to OpenAPI.
Practical value of this chapter
Design in practice
Use guidance on API security patterns, security contracts, and abuse mitigation to define architectural security requirements before implementation starts.
Decision quality
Validate solutions through threat model, security invariants, and production control operability, not compliance checklists alone.
Interview articulation
Frame answers as threat -> control -> residual risk, linking business scenario to concrete protection mechanisms.
Trade-off framing
Make trade-offs explicit for API security patterns, security contracts, and abuse mitigation: UX friction, latency overhead, operational cost, and compliance constraints.
Context
OWASP Top 10 in the context of System Design
API security operationalizes OWASP risks for your system's API surface.
API Security Patterns ensure APIs remain secure under load, in multi-tenant settings, and against active attackers. The discipline combines protocol design, access policy, abuse protection, and operational observability.
Core API security patterns
Strong AuthN + short-lived tokens
OIDC/OAuth2, mTLS for service-to-service, token rotation, and clear revocation strategy.
Fine-grained AuthZ
RBAC/ABAC, tenant-scoped permissions, policy engines, and deny-by-default in gateways and services.
Input/Schema validation
Strict JSON schema/OpenAPI checks, canonicalization, and rejection of unknown fields.
Rate limiting + abuse controls
Per user/app/tenant quotas, burst control, bot detection, and adaptive throttling.
Anti-replay and request signing
Nonce + timestamp + HMAC/signature, clock-skew policy, and request expiration windows.
Zero-trust network posture
No internal API is trusted by default: mutual authentication + network segmentation.
Typical attack scenarios
BOLA/IDOR on object-level APIs
Risk: A user reaches another tenant's objects with valid authentication but weak authorization.
Mitigation: Object-level policy checks, tenant isolation, deny-by-default, and ownership validation.
Token replay
Risk: A captured token is replayed and used for privileged operations.
Mitigation: Short-lived tokens, nonce/timestamp checks, sender-constrained tokens, and anomaly detection.
Mass assignment and schema abuse
Risk: Attackers pass extra fields and mutate protected model attributes.
Mitigation: Strict allow-list schemas, reject unknown fields, and server-side ownership checks.
API scraping and business abuse
Risk: Legitimate endpoints are abused for large-scale scraping or fraud automation.
Mitigation: Adaptive rate limits, behavior signals, per-tenant quotas, and layered anti-bot controls.
Secure API lifecycle
Without a closed security loop, API protection degrades into isolated fixes. The lifecycle below creates a continuous feedback cycle from design to operations.
Current step
1. Design
Define trust boundaries, abuse scenarios, and security requirements before coding: who calls the API, what data flows through it, and where privilege escalation is possible.
- • STRIDE/LINDDUN across endpoint groups and business flows
- • Explicit AuthN/AuthZ model, tenant isolation, and data classification
- • Security acceptance criteria in OpenAPI/ADR
Next step
2. Build
Embed checks directly into the pipeline: code, dependencies, and secrets are validated automatically before merge and artifact promotion.
- • SAST + secret scanning + dependency/SBOM scan
- • Lint/OpenAPI checks: auth scopes, schema strictness, rate-limit hints
- • Standard middleware/libraries for auth, input validation, and signature checks
API security control matrix
| Area | Controls | Validation approach | Action on failure |
|---|---|---|---|
| Identity and Access | OAuth2/OIDC, mTLS, JWT claim checks, RBAC/ABAC. | AuthN/AuthZ test suites and forbidden-path integration tests. | Block request, log policy decision, alert security owner. |
| Input and Schema | OpenAPI contract validation, canonicalization, strict parsing. | Negative tests, fuzzing, and schema-drift checks in CI. | Reject payload with explicit error code and abuse signal tagging. |
| Abuse and Availability | Rate limits, WAF rules, idempotency keys, replay protection. | Load/adversarial testing, bot simulation, replay drills. | Throttle or block source and auto-escalate repeated patterns. |
| Sensitive Data | Field-level masking, minimization, encryption in transit and at rest. | Log inspection checks, DLP scans, and PII-safe response snapshots. | Mask output, quarantine endpoint, open compliance incident. |
| Observability and Response | Audit logs, security metrics, trace correlation with tenant context. | Incident playbook drills, detection-rule validation, MTTR reviews. | Activate containment playbook and temporary hardening policies. |
Data
Data Governance & Compliance
API layers are often the primary leakage path for PII without proper data policies.
Sensitive data rules for APIs
Never return sensitive fields by default; explicit allow-list only.
Mask or fully exclude PII in logs and traces.
API versioning must preserve security guarantees for older clients.
Public and internal APIs require different security baselines and keys.
Error responses must not leak internal service, DB, or policy details.
Operational metrics
Unauthorized request block rate
Target: 100%
Confirms deny-by-default behavior for unauthenticated and invalid requests.
P95 security validation latency
Target: < 30 ms
Security controls must not materially degrade API UX or SLO targets.
Critical API vulnerability remediation time
Target: < 24 hours
Measures response speed for high-risk findings on public API surfaces.
Replay/abuse incident MTTR
Target: < 60 minutes
Faster containment reduces financial and reputational impact.
Rollout roadmap
Phase 1 (0-30 days)
Focus: API surface inventory
Outcome: API catalog, risk classification, and accountable owner for each public contract.
Phase 2 (30-60 days)
Focus: Mandatory baseline controls
Outcome: Unified AuthN/AuthZ policy, schema validation, and gateway rate limits.
Phase 3 (60-90 days)
Focus: Abuse resilience
Outcome: Anti-replay, anti-bot controls, telemetry correlation, and detection automation.
Phase 4 (90+ days)
Focus: Operational maturity
Outcome: Regular security game days, metric reviews, and continuous hardening backlog.
Typical antipatterns
Rely only on perimeter security and skip auth checks inside services.
Mix user and machine tokens without an explicit privilege model.
Retry write APIs without anti-replay and idempotency guards.
Log full request bodies in production.
Disable strict schema validation to ship faster.
References
Related chapters
- OWASP Top 10 in the context of System Design - Maps core risk classes that appear in APIs as BOLA, mass assignment, and auth bypass scenarios.
- Identification, authentication and authorization - Provides the IAM foundation required for enforceable API security controls.
- Zero Trust: a modern approach to architectural security - Extends API security to architecture-level policy evaluation for every request.
- Secrets Management Patterns - Covers secure handling of API keys, client secrets, and token material in runtime and CI/CD.
- Data Governance & Compliance - Adds PII handling policies, auditability, and regulatory constraints for API data flows.