Slide 19 of 28
Part 4 · PreventionSlide 19
Slide 19 · Mitigation 1
MIT 01
Rate limiting — cap how many requests any client can make per time window.

Define explicit request limits for every API endpoint. Track consumption per client (by user ID, API key, or IP address) in a fast store (Redis is standard). Return HTTP 429 Too Many Requests when the limit is exceeded. Include a Retry-After header so legitimate clients can back off gracefully.

Limits should vary by endpoint sensitivity:

Authentication endpoints: 5–10 requests/minute per IP (defense against credential stuffing)

OTP / SMS endpoints: 3–5 requests/hour per phone number + 10/hour per IP

Search/list endpoints: 60–120 requests/minute per user

Write endpoints: 30–60 requests/minute per user

Public/unauthenticated endpoints: 10–30 requests/minute per IP

Rate limit on multiple dimensions simultaneously. Limiting by user ID stops authenticated abuse. Limiting by IP stops anonymous abuse and credential stuffing. For particularly sensitive operations, limit by the target (e.g., phone number) to prevent flooding a specific victim regardless of how many IPs the attacker rotates through.

API gateway (Kong, AWS API Gateway, Apigee), middleware libraries (express-rate-limit, django-ratelimit, rack-attack), or infrastructure layer (nginx limit_req). Implement at the gateway layer where possible — it applies to all endpoints without touching application code.

💼 Business takeaway

Ask your team whether your API has rate limits — and whether those limits apply per user, per API key, and per IP address. “We’ll add it later” is how this vulnerability persists until a bill arrives or a service goes down.

← Back MIT 02: Maximum page size →