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

Source: https://securitypatterns.distrinet-research.be/patterns/02_03_001__limit_request_rate/
OWASP Rate Limiting
RFC 6585 (429 Too Many Requests)

limit-request-rate-pattern

Safety Notice

Copy this and send it to your AI assistant to learn