skills/igbuend/grimbard/limit-request-rate-pattern

limit-request-rate-pattern

SKILL.md

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

Weekly Installs
3
GitHub Stars
4
First Seen
Feb 19, 2026
Installed on
openclaw3
claude-code3
replit3
codex3
kiro-cli3
kimi-cli3