Security6 min read

API Security

Secure APIs against authentication bypass, injection, data exposure, and abuse - covering JWT, OAuth 2.0, rate limiting, input validation, and API gateway patterns.

API SecurityOAuthJWTRate LimitingAuthentication

skill: API Security category: Security tags: [API Security, OAuth, JWT, Rate Limiting, Authentication] readingTime: 6

APIs are the primary attack surface of modern applications. OWASP API Top 10 identifies the most critical API vulnerabilities - broken object-level authorization, broken authentication, excessive data exposure, and lack of rate limiting are the most common. Treat every API input as hostile.

Workflow

Implement JWT correctlyJWTs are widely misimplemented - algorithm confusion attacks, weak secrets, and missing expiry are all common critical vulnerabilities.
Implement OAuth 2.0 authorization code flowOAuth 2.0 delegates authentication to trusted providers (Google, GitHub) - eliminating password storage and leveraging provider MFA.
Enforce object-level authorization (IDOR prevention)The #1 OWASP API vulnerability - a user can access another user's resource by changing an ID in the URL. Always check ownership.
Apply rate limiting per endpointWithout rate limiting, your API is open to brute-force attacks on auth endpoints and abuse of expensive operations.
Return minimal data - avoid excessive exposureAPIs often return entire DB objects when the client only needs 3 fields. Excessive data exposure leaks sensitive information and increases bandwidth.

Output Format

Secure API: JWT with explicit algorithm, OAuth 2.0 PKCE, object-level authorization, rate limiting, and minimal response data.

API Security Layers:
1. Authentication: JWT (HS256, exp), OAuth 2.0
2. Authorization: role check + object ownership per endpoint
3. Input validation: Zod/Pydantic schema on all inputs
4. Rate limiting: 5 req/15min on auth, 100 req/15min on API
5. Output: DTO/serializer - never raw DB objects
6. Headers: CORS (specific origins), no server version

Examples

Input

Output

Edge Cases & Gotchas

Token storage XSS risk - Storing JWTs in localStorage exposes them to XSS attacks. Store in httpOnly cookies to prevent JavaScript access - but then handle CSRF protection (SameSite=Strict).
Refresh token rotation - Refresh tokens that never rotate are as dangerous as long-lived access tokens. Implement refresh token rotation: each use issues a new refresh token and invalidates the old one.
API versioning and deprecation - Old API versions accumulate technical debt and security vulnerabilities. Set a deprecation timeline, communicate via Sunset headers, and decommission after the deadline.
Webhook signature verification - Webhooks from third parties can be spoofed. Always verify the HMAC-SHA256 signature in the webhook header against your secret before processing.

When to Break These Rules

Use an API gateway (Kong, AWS API Gateway, Apigee) for centralized rate limiting, auth, and logging across many services - per-service implementation is harder to maintain consistently.
Use mTLS (mutual TLS) instead of JWT for machine-to-machine authentication - it provides stronger identity guarantees at the infrastructure level.

Reference Files

https://owasp.org/API-Security/editions/2023/en/0x11-t10/
https://jwt.io/introduction/