API Security

APIs are the connective tissue of modern applications — they expose business logic, exchange sensitive data, and integrate third-party services. A compromised API can bypass every perimeter control in place. This guide aligns to NIST SP 800-204 (Security Strategies for Microservices-based Application Systems), NIST SP 800-95 (Guide to Secure Web Services), and NIST SP 800-53 Rev 5, and incorporates the OWASP API Security Top 10 (2023).

1. Authentication

Every API request must be authenticated. Anonymous access should be an explicit, audited decision — not the default.

API Keys

Suitable for server-to-server communication where the client environment is controlled.

Authorization: ApiKey <key>

Avoid ?api_key= in URLs. Query parameters appear in server logs, browser history, and referrer headers.

OAuth 2.0 / OpenID Connect

Use for delegated authorisation where a third party acts on behalf of a user.

Token requirements (NIST SP 800-63B §4):
- Access tokens: short-lived (≤ 15 minutes)
- Refresh tokens: bound to client, rotated on use
- Validate iss, aud, exp, nbf on every request
- Use asymmetric signing (RS256 / ES256) — avoid HS256 in distributed systems

Mutual TLS (mTLS)

For high-assurance service-to-service authentication. Both parties present certificates, establishing cryptographic proof of identity at the transport layer. Aligns to NIST SP 800-204A service mesh security.

Client → (presents cert) → API Gateway → (validates cert) → Backend

mTLS is the preferred authentication mechanism for internal microservice APIs.

2. Authorisation

Authentication answers who are you? — authorisation answers what are you allowed to do?

Principle of Least Privilege (NIST AC-6)

• Issue tokens with minimum required scopes
• Validate scopes on every endpoint, not just at the gateway
• Never infer permissions from data in the request body

Broken Object Level Authorisation (BOLA)

The most exploited API vulnerability (OWASP API1:2023). Occurs when an API accepts a user-supplied identifier and returns or modifies the associated object without verifying the requestor owns it.

# Vulnerable
GET /api/orders/8821        ← attacker changes their order ID to another user's

# Mitigated
GET /api/orders/8821        ← server resolves the order by combining JWT subject + order ID

Mitigation:
- Always authorise at the object level, not just the endpoint level
- Use indirect references (UUIDs, opaque tokens) rather than sequential integers
- Enforce ownership checks server-side regardless of what the client sends

Broken Function Level Authorisation (BFLA)

Horizontal privilege escalation through undocumented or administrative endpoints.

• Disable all endpoints not explicitly required
• Apply role checks at the function level, not only at the router
• Never rely on URL obscurity as an access control

3. Rate Limiting & Throttling

Rate limiting is a NIST SI-17 (Fail-Safe Procedures) and AC-7 (Unsuccessful Login Attempts) control. Without it, APIs are vulnerable to brute-force attacks, credential stuffing, denial of service, and scraping.

Limit Dimensions

Apply limits across multiple dimensions simultaneously:

Response Headers

Communicate limits to consumers so clients can self-regulate:

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 743
X-RateLimit-Reset: 1720000000
Retry-After: 60

Return HTTP 429 Too Many Requests when a limit is exceeded — never silently drop requests.

Algorithms

Distributed Rate Limiting

In multi-instance deployments, counters must be stored in a shared cache (Redis, Memcached) — not in process memory. Per-instance limits result in effective limits that are a multiple of the configured value.

4. Input Validation & Schema Enforcement

NIST SI-10 (Information Input Validation) requires validating all inputs for type, format, length, and range before processing.

API Schema Validation

Define a schema contract and enforce it on every request:

• REST: OpenAPI 3.x (formerly Swagger) — validate requests against the schema at the gateway
• GraphQL: Schema introspection; disable in production; use query depth/complexity limits
• gRPC: Protocol Buffers provide built-in type enforcement

Validation Rules

Mass Assignment

Attackers supply additional properties the server never expected to receive.

// Attacker adds "role" to a user-update request
{ "name": "Alice", "email": "alice@example.com", "role": "admin" }

Mitigation: Use an explicit allow-list of accepted properties. Never pass raw request bodies directly to data models (ORM or otherwise).

5. Transport Security

NIST SC-8 mandates cryptographic protection of data in transit.

• TLS 1.3 required; TLS 1.2 acceptable with strong cipher suites
• Disable TLS 1.1 and below
• Enforce HSTS on all API domains: Strict-Transport-Security: max-age=31536000; includeSubDomains
• Pin certificates for high-value internal services (mTLS)
• Never transmit secrets (tokens, keys, passwords) in query parameters

6. API Lifecycle Management

Unmanaged APIs are a leading source of security debt. NIST SP 800-204 emphasises lifecycle controls across design, deployment, and retirement.

Inventory & Discovery

You cannot secure what you do not know exists.

• Maintain a centralised API registry (gateway catalogue, API management platform)
• Run discovery scans to detect shadow APIs not registered in the catalogue
• Include APIs in the CMDB and tie them to owners and data classifications

Versioning

Deprecation Process

1. Announce deprecation date via Deprecation and Sunset response headers
2. Log and alert when deprecated endpoints are called
3. Notify registered consumers directly before shutdown
4. Remove the version on the announced date — do not silently maintain it indefinitely

Deprecation: Sat, 01 Jan 2027 00:00:00 GMT
Sunset: Sat, 01 Jan 2027 00:00:00 GMT
Link: <https://api.example.com/v2/users>; rel="successor-version"

Decommissioning

A decommissioned API that still responds is an attack surface. Ensure:

• Gateway routes removed
• Backend services stopped
• Credentials and tokens revoked
• DNS records removed or redirected
• Audit log retained per data retention policy

7. API Gateway

An API gateway is the primary enforcement point for cross-cutting security controls. Do not rely on each individual service to re-implement authentication, rate limiting, and logging.

Gateway Responsibilities

Gateway Security Hardening

• Strip internal headers (X-Internal-User-ID) before forwarding external requests
• Reject requests with unexpected Host headers
• Set hard timeouts on upstream connections (prevent slowloris)
• Return generic error messages to callers; log detailed errors internally
• Do not pass raw client errors from upstream services back to callers

8. Logging, Monitoring & Alerting

NIST AU-2 and AU-12 require that APIs generate audit records for security-relevant events.

What to Log

What NOT to Log

• Passwords, API keys, or tokens in any field
• Full request bodies containing PII without explicit masking
• Credit card numbers, SSNs, or other regulated data

Detection Patterns

Configure alerts on:
- Spike in 401 / 403 responses (credential stuffing, BOLA probing)
- Spike in 429 responses (rate abuse, DoS)
- Sequential object ID enumeration (incrementing IDs in paths)
- Access to deprecated endpoints (may indicate unpatched client or attacker using old intel)
- Unusual off-hours access patterns

9. OWASP API Security Top 10 (2023)

10. Common Pitfalls

API Security Checklist

Regulatory & Standards Reference