| name | limit-request-rate-pattern |
| description | Security pattern for implementing rate limiting and throttling. Use when protecting against brute-force attacks, DoS/DDoS mitigation, preventing resource exhaustion, or limiting API abuse. Addresses "Entity absorbs excessive resources" problem. |
Limit Request Rate Security Pattern
Limits the number of requests an entity can make within a given timeframe, preventing resource exhaustion and brute-force attacks.
Problem Addressed
Entity absorbs excessive resources: An attacker floods the system with requests, either to:
- Exhaust system resources (DoS)
- Brute-force authentication credentials
- Enumerate valid identifiers
- Abuse expensive operations
Core Components
| Role | Type | Responsibility |
|---|
| Entity | Entity | Makes requests to system |
| Enforcer | Enforcement Point | Intercepts and rate-checks requests |
| Limiter | Decision Point | Decides if request within limits |
| Policy Provider | Information Point | Manages rate limit rules |
| History Store | Storage | Tracks request history per entity |
Data Elements
- id: Identifier for the entity (IP, user, API key)
- history: Record of entity's previous requests
- policy: Rules defining allowed request rates
- action: The requested operation
Rate Limiting Flow
Entity → [action] → Enforcer
Enforcer → [check(id)] → Limiter
Limiter → [get_policy(id)] → Policy Provider
Policy Provider → [policy] → Limiter
Limiter → [get_history(id)] → History Store
History Store → [history] → Limiter
Limiter → [allowed/denied] → Enforcer
Enforcer → [action] → System (if allowed)
→ [429 Too Many Requests] → Entity (if denied)
Entity Identification
How to identify entities for rate limiting:
| Identifier | Pros | Cons |
|---|
| IP Address | Simple, no auth needed | NAT/proxy issues, IPv6 abundant |
| User/API Key | Accurate per-user | Requires authentication |
| Session ID | Works for logged-in users | Session rotation may reset |
| Combination | More precise | Complex implementation |
Recommendation: Use multiple identifiers where possible.
Rate Limiting Algorithms
Fixed Window
- Count requests in fixed time periods
- Simple but allows bursts at window boundaries
- Example: 100 requests per minute
Sliding Window
- Rolling time window
- Smoother rate enforcement
- More memory intensive
Token Bucket
- Tokens added at fixed rate
- Request consumes token
- Allows controlled bursts
- Good for APIs
Leaky Bucket
- Requests queued and processed at fixed rate
- Smooths traffic
- May add latency
Policy Configuration
Define policies based on:
- Endpoint sensitivity: Stricter limits on auth endpoints
- User type: Different limits for free vs. paid users
- Operation cost: Stricter limits on expensive operations
- Time of day: Adjusted limits for peak periods
Example policies:
/login: 5 requests per minute per IP
/api/search: 100 requests per minute per API key
/api/export: 10 requests per hour per user
Security Considerations
Authentication Endpoints
- Aggressive rate limiting on login
- Limit by IP AND username
- Exponential backoff after failures
- Consider CAPTCHA after threshold
Distributed Attacks
- Single IP limits insufficient
- Monitor aggregate patterns
- Consider global rate limits
- Use reputation services
Response Headers
Inform clients of limits:
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1640000000
Retry-After: 60
Failure Handling
- Rate limiting infrastructure must be resilient
- Fail-open vs. fail-closed decision
- Don't let rate limiter become DoS vector
Bypass Prevention
- Ensure rate limiter cannot be circumvented
- Apply at edge/gateway level
- Rate limit before expensive operations
Implementation Approaches
Application Level
- Fine-grained control
- Access to user context
- Higher overhead
API Gateway Level
- Central enforcement
- Consistent across services
- May lack context
Infrastructure Level (CDN/WAF)
- Handles volumetric attacks
- Limited application context
- Good first line of defense
Recommendation: Defense in depth—use multiple levels.
Implementation Checklist
Related Patterns
- Authentication (protect login endpoints)
- Authorisation (rate limit authorization checks)
- Data validation (rate limit before validation)
References
