Chapter 8 — API Security & Rate Limiting

The why

Without rate limiting, one angry user with a while(true) loop can take down your API. One scraper can drain your database. One credential-stuffer can brute-force 100,000 passwords. Rate limiting is not a nice-to-have — it's the difference between a resilient API and a fragile one.

Core concepts

Rate limiting algorithms

Sliding window implementation (Redis)

const redis = require('redis');
const client = redis.createClient({ url: process.env.REDIS_URL });
 
async function rateLimit(key, maxRequests, windowSeconds)

Rate limit middleware

function rateLimiter(maxRequests, windowSeconds) {
  return async (req, res, next) => {
    // Per-user: authenticated users get their own bucket
    // Per-IP: unauthenticated requests
    const key = req.userId ? `user:${

Tiered rate limiting (per-user, per-IP, per-endpoint)

Production APIs use tiered limits:

const LIMITS = {
  anonymous: { window: 60, max: 20 },      // 20 req/min for unauthenticated
  free:      { window: 60, max: 100 },     // 100 req/min for free users
  pro:       { window: 60, max:

Abuse detection beyond rate limiting

Rate limiting prevents volume attacks. Abuse detection catches pattern-based attacks:

// Detect credential stuffing: many different usernames from same IP
async function detectCredentialStuffing(ip) {
  const key = `login_attempts:${ip}:${Math.floor(Date.now() / 60000)}`;
  const uniqueUsers = await

Real-world example: How GitHub handles rate limiting

GitHub's API rate limits are industry-standard:

1. Authenticated users: 5,000 requests/hour. Unauthenticated: 60 requests/hour.
2. Headers in every response: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset (epoch seconds).
3. Secondary limits (abuse detection): Even within the primary limit, GitHub detects abusive patterns (rapid consecutive requests to the same endpoint) and issues a secondary rate limit.
4. Conditional requests encouraged: Use If-None-Match (ETag) and If-Modified-Since — requests that return 304 Not Modified don't count against your limit.

Common mistakes

Production notes

• Use Redis with Lua scripts for atomic rate limit operations. The check-and-increment must be atomic, or concurrent requests can exceed the limit.
• Set different limits per endpoint. Login: 5/15min. API: 100/min. Admin: 500/min. File upload: 10/min.
• Respect Retry-After. Good API consumers will back off. Bad ones will get blocked by your WAF eventually.

Performance notes

• Redis rate limit check: ~0.3ms (single Lua script execution). Negligible overhead.
• In-memory fallback. If Redis is down, fall back to an in-memory rate limiter with a warning log. Never fail open.
• Distributed rate limiting. If you have 10 API servers, Redis is the shared state. Without it, each server has its own counter — users can send 10x the limit by hitting different servers.

Security notes

• Rate limit is a security control, not just a performance control. It prevents brute force, credential stuffing, DDoS, and scraping.
• Don't leak rate limit information unnecessarily. 429 responses are fine. Detailed error messages ("You have 3 attempts remaining") for login endpoints are a tradeoff: good UX, but helps attackers pace their attacks.

Exercises

Beginner

1. Implement a fixed-window rate limiter (in-memory) that limits to 10 requests per minute. Test with a loop that sends 15 rapid requests — verify the last 5 get 429.
2. Add the standard rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) to your responses.

Intermediate

1. Implement a sliding-window rate limiter using Redis sorted sets. Test boundary behavior: 100 requests at 59 seconds + 100 at 1 second should correctly limit.
2. Implement tiered rate limiting: anonymous users get 20/min, authenticated users get 100/min, admin users get 1000/min.

Advanced

1. Implement token bucket rate limiting with Redis. Compare its burst-handling behavior with the sliding window approach. Which is better for your use case?
2. Build a rate limit dashboard: show current consumption per user, detect users approaching their limit, and provide an admin API to temporarily increase limits.

Interview questions

Beginner

1. Why is rate limiting important? Prevents abuse (brute force, credential stuffing), protects against DDoS, ensures fair resource usage across users, and prevents a single user from degrading service for everyone else.

2. What HTTP status code does rate limiting return? 429 Too Many Requests. Should include a Retry-After header telling the client when to retry.

3. What's the problem with fixed-window rate limiting? The boundary problem — a user can send 2x the limit in a short burst by straddling the window boundary (e.g., max at second 59, then max again at second 1).

Senior

4. Compare sliding window vs token bucket for rate limiting. Sliding window: counts requests in the last N seconds. Accurate, simple concept. Token bucket: tokens refill at a constant rate, bursts are allowed up to bucket capacity. Token bucket is better for allowing short bursts while maintaining a long-term average. Sliding window is better for strict per-second/minute limits.

5. How do you rate limit in a distributed system with multiple API servers? Use a shared state store (Redis) with atomic operations (Lua scripts). Each server checks and updates the shared counter. Without shared state, an attacker can exceed the limit by distributing requests across servers. Fall back to local rate limiting if Redis is unavailable (with degraded accuracy).

6. How would you design rate limiting for a multi-tenant SaaS where tenants have different plans? Per-tenant limits stored in the database (cached in Redis). On each request: identify tenant from API key or JWT, look up their tier's limit, check against their current usage in Redis. Allow tenant admins to view their usage. Allow temporary limit increases via a support/admin API. Bill for overages or hard-cutoff at limit depending on the business model.

Summary

Rate limiting is essential for API resilience and security. Use sliding window (Redis sorted sets with Lua) for accuracy. Set tiered limits: per user (authenticated), per IP (anonymous), per endpoint (login stricter than general API). Always include X-RateLimit-* and Retry-After headers. Redis for distributed state. Monitor 429 rates to tune limits. Rate limiting is a security control — it prevents brute force, credential stuffing, and DDoS.

Quick recall

• Sliding window (Redis Sorted Sets + Lua) for most use cases.
• 429 Too Many Requests + Retry-After header.
• Tiered: per user, per IP, per endpoint. Stricter on login/password-reset.
• Exclude health checks and metrics from rate limiting.
• Redis for distributed state. In-memory fallback with degraded accuracy.
• Headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset.

Quiz

1. What status code do you return for rate-limited requests? 429 Too Many Requests.
2. What's the problem with fixed-window rate limiting? Boundary problem — 2x burst at window edge.
3. Why use Redis for rate limiting in a distributed system? Shared state across API servers. Without it, each server counts independently.
4. What header tells the client when to retry? Retry-After (seconds until the limit resets).
5. Which endpoints should have stricter rate limits? Login, registration, password reset, token refresh — anything that validates credentials.
6. What's token bucket useful for that sliding window isn't? Allowing short bursts (up to bucket capacity) while maintaining a long-term average rate.
7. How do you prevent rate limiting from blocking your own monitoring? Exclude /health, /metrics, and internal IP ranges from rate limits.