limit-request-rate-pattern

# 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 - [ ] Authentication endpoints rate limited - [ ] Limits per IP AND per user where applicable - [ ] Appropriate algorithm selected - [ ] Rate limit headers returned - [ ] 429 responses with Retry-After - [ ] Limits at multiple levels (app, gateway, CDN) - [ ] Monitoring and alerting on limits hit - [ ] Distributed attack patterns detected - [ ] Expensive operations protected - [ ] Fail behavior defined ## Related Patterns - Authentication (protect login endpoints) - Authorisation (rate limit authorization checks) - Data validation (rate limit before validation) ## References - Source: https://securitypatterns.distrinet-research.be/patterns/02_03_001__limit_request_rate/ - OWASP Rate Limiting - RFC 6585 (429 Too Many Requests)