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)
More from igbuend/grimbard
tikz
LaTeX TikZ/PGF package for programmatic vector graphics and diagrams. Use when helping users draw flowcharts, trees, graphs, automata, circuits, geometric figures, or any custom diagram in LaTeX.
91latex
Comprehensive LaTeX reference for document creation, formatting, mathematics, tables, figures, bibliographies, and compilation. Use when helping users write, edit, debug, or compile LaTeX documents.
37pgfplots
LaTeX pgfplots package for data visualization and plotting. Use when helping users create line plots, bar charts, scatter plots, histograms, 3D surfaces, or any scientific/data plot in LaTeX.
31biblatex
LaTeX biblatex/biber packages for modern bibliography management. Use when helping users cite references, manage .bib files, choose citation styles, or troubleshoot bibliography compilation.
24ethical-hacking-ethics
Legal and ethical guidelines for bug bounties, pentesting, and security research. Use when conducting authorized security testing.
12codebase-discovery
Generate security-focused DISCOVERY.md for code review and threat modeling. Use when assessing unfamiliar codebases.
11