Context
OWASP Top 10 in the context of System Design
API security is a specification of OWASP risks for the API surface of your system.
API Security Patterns are responsible for ensuring that APIs remain secure under load, in a multi-tenant environment and in the presence of active attackers. It is a combination of protocols, access policies, abuse protection and observability.
Core API security patterns
Strong AuthN + short-lived tokens
OIDC/OAuth2, mTLS for service-to-service, token rotation and revocation strategy.
Fine-grained AuthZ
RBAC/ABAC, tenant-scoped permissions, policy engine and deny-by-default in gateway and services.
Input/Schema validation
Strict JSON schema/OpenAPI checks, canonicalization and reject 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 window.
Zero-trust network posture
No internal API is trusted by default: mutual auth + network segmentation.
Secure API lifecycle
Without a closed security loop, API protection quickly degrades to point fixes. Below is a practical loop, where each stage generates inputs for the next and feeds back into the design.
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
Data
Data Governance & Compliance
The API field is often the main channel for leaking PII without the right data policies.
Sensitive data rules for APIs
Never revert sensitive fields to default; explicit allow-list only.
PII in logs/trace is masked or completely excluded.
API versioning should not violate the security guarantees of older clients.
Public and internal APIs have different security baselines and access keys.
Typical antipatterns
Rely only on perimeter security and do not check auth inside the service.
Mix user and machine tokens without an explicit privilege model.
Retry without anti-replay and idempotency guard in the write API.
Log the entire request body in production.