IP Rate Limiting

What is IP rate limiting?

IP rate limiting restricts how many requests a single IP address can make to a service within a time window — for example, “no more than 100 requests per minute per IP.” It’s a specific, very common application of the broader rate limiting concept, using the client’s IP address as the identifier to track and throttle. It’s typically one of the first lines of defense against abuse: mitigating brute-force login attempts, slowing down scrapers and bots, blunting some denial-of-service traffic, and enforcing fair usage — all keyed on “how much is this IP asking for?” Because it needs no authentication or API key (the IP is always available), it’s easy to deploy at the edge and is nearly ubiquitous.

Where it’s used, and how it’s enforced

IP rate limiting shines for unauthenticated traffic where you have no better identifier than the source IP: the login endpoint (limiting attempts per IP is a core defense against credential-stuffing and brute-force password guessing), public API endpoints without keys, signup/contact forms (blunting spam bots), and general edge protection against scraping and floods. It’s enforced at the point traffic enters — an API gateway, load balancer, reverse proxy, CDN/WAF — so abusive requests are rejected (typically with HTTP 429 Too Many Requests) before reaching application servers. In distributed systems the per-IP counter usually lives in a shared fast store like Redis so all nodes enforce one consistent limit per IP rather than each node counting separately (which would let the real limit be N× higher). The same algorithm choices as general rate limiting apply (token bucket, sliding window, etc.), and well-behaved implementations return Retry-After headers so legitimate clients can back off gracefully.

The critical limitations — why IP alone isn’t enough

The most important thing to understand is that IP address is a flawed identifier, and relying on IP rate limiting alone has well-known weaknesses that cut both ways. It’s easily evaded by determined attackers: a single actor can spread requests across many IPs — botnets, proxy/VPN pools, cloud IP ranges, and rotating residential proxies make it cheap to distribute an attack so no single IP trips the limit, defeating per-IP throttling. So IP rate limiting raises the bar against casual abuse but doesn’t stop a distributed, motivated attacker. It causes false positives in the other direction, because many legitimate users can share one IP: users behind carrier-grade NAT, a corporate office, a university, or a shared proxy all appear as the same IP, so a per-IP limit tuned for one user can wrongly throttle a whole building of legitimate people (or, on IPv6, the opposite problem — a single user with a vast address range can rotate freely). This shared-IP reality means IP rate limits must be set thoughtfully and can’t be too aggressive without harming real users. The practical conclusion: IP rate limiting is a useful layer, not a complete solution. It should be combined with other identifiers and defenses — rate limiting by user account/API key (for authenticated traffic, far more precise than IP), device fingerprinting, CAPTCHA challenges on suspicious activity, behavioral analysis, and dedicated bot-management/WAF and DDoS-protection services for distributed attacks. For login specifically, per-IP limits should be paired with per-account limits (so an attacker spreading across IPs still hits an account-level cap) and account-lockout/MFA defenses. The recurring mistakes: treating IP rate limiting as sufficient anti-abuse on its own (evaded by IP rotation), setting limits too aggressively without accounting for shared IPs (throttling legitimate NAT/corporate users), enforcing per-node instead of shared counters (real limit ends up N× intended), and not layering it with account-level limits and bot defenses.

What people get wrong

• Treating it as sufficient — attackers rotate across many IPs (botnets, proxies) to evade per-IP limits; it’s one layer that must be combined with account-level limits, bot management, and DDoS protection.
• Ignoring shared IPs: carrier-grade NAT, offices, and universities put many legitimate users behind one IP, so aggressive per-IP limits cause false positives — tune carefully and prefer per-account limits where users authenticate.
• Per-node counters — without a shared store (e.g., Redis), each server enforces its own per-IP count and the real limit becomes N× what you intended; enforce one consistent limit across nodes.

Primary source: MDN: 429 Too Many Requests