Rate Limiting by IP Address: Designing Limits for Shared IP Environments
Effective rate limiting by IP address is challenging with shared IPs. This article details how to design robust limits that handle proxies, VPNs, and NAT.
Rate limiting is a fundamental defense mechanism for protecting web applications and APIs from abuse, resource exhaustion, and denial-of-service attacks. The simplest and most common approach involves tracking requests per IP address. However, this method quickly breaks down in the face of modern network realities: shared IP addresses.
Shared IPs are everywhere: enterprise NATs, mobile carrier networks, public Wi-Fi, VPNs, proxies, and TOR exit nodes. Relying solely on the source IP to identify a unique user or entity will inevitably lead to either blocking legitimate users (false positives) or allowing sophisticated attackers to bypass limits by rotating through shared IPs (false negatives).
This article outlines strategies to design rate limits that are more resilient to shared IP environments, moving beyond a simple /32 or /128 IP-based count.
The Core Problem: IP Address != User
Historically, an IP address often correlated strongly with a single user or a small group of users behind a static NAT. Today, this assumption is flawed:
- Mobile Carriers: Thousands, or even tens of thousands, of users can share a single public IPv4 address via Carrier-Grade NAT (CGNAT).
- Enterprise Networks: Large organizations often funnel all outbound traffic through a limited pool of public IPs.
- Public Wi-Fi/Hotspots: Many users simultaneously connect via a single gateway IP.
- Proxies, VPNs, TOR: These services explicitly pool users behind shared IPs for privacy or bypass purposes. Attackers leverage this for anonymity and to distribute load across many IPs.
- Cloud Providers/Data Centers: Workloads running in cloud environments or data centers often originate from large, well-known IP ranges shared by numerous tenants.
When a large number of legitimate users share an IP, a simple per-IP rate limit will quickly trigger, blocking them all. Conversely, an attacker can rotate through a pool of proxy IPs, each seemingly under the rate limit, to collectively exceed the intended threshold.
Beyond Simple IP: Augmenting Rate Limiting Signals
To build more robust rate limits, we must incorporate additional signals beyond the immediate source IP.
1. User-Centric Identifiers
When available and appropriate, associate rate limits with a user ID rather than solely an IP. This is ideal for authenticated actions.
- Session ID/Cookie: Track requests per session. This helps identify repeated actions from the same