Section 30 · API & Security
Rate Limiting
Audit guide for rate limiting configuration, behavior, and documentation.
This guide walks you through auditing a project's rate limiting configuration - how requests are throttled, how limits are enforced, and how consumers are informed.
The Goal: Protected Endpoints
APIs must defend themselves against abuse while remaining usable for legitimate consumers who understand the boundaries.
- Active throttling — rate limiting at infrastructure or application level protects against abuse and DoS
- Client isolation — limits keyed on IP, user ID, or API key so one consumer cannot exhaust limits for others
- Graceful rejection — proper 429 responses with helpful information when limits are exceeded
- Discoverable limits — consumers can learn limits through documentation or response headers before hitting them
Before You Start
- Identify infrastructure (Cloudflare, nginx, AWS API Gateway, etc.)
- Identify application framework (Express, Fastify, Django, Flask, etc.)
- Understand API architecture (REST, GraphQL, internal vs public)
- Check for existing rate limit libraries in dependencies
general
Rate limiting exists at infrastructure or application level with proper client isolation
“Could one angry script hit your API until it falls over?”
Rate-limited requests return proper 429 responses with helpful information
“What does your client actually do when it gets rate-limited?”
API consumers can discover rate limits via documentation or response headers
“Do your API consumers know they're about to hit a wall?”