IP rotation, X-Forwarded-For spoofing, race conditions, distributed brute-force. When the only defence between an attacker and every account is a Redis counter, the attacker has options.
Rate limiting is often the last line of defence against credential stuffing, brute-force login attacks, and enumeration. But attackers have a toolbox of bypass techniques — IP rotation, header spoofing, race conditions, and distributed botnets — that turn a rate limiter into a speed bump rather than a barrier.
Rate limiting is implemented by tracking request frequency per IP address, per user account, or per session. A typical rule might allow 5 login attempts per minute per IP. This stops a single attacker running a brute-force script from their home connection. But it does not stop an attacker who controls thousands of IPs through a residential proxy network — each IP makes one or two attempts and moves on.
The X-Forwarded-For header presents another bypass. Many applications are deployed behind reverse proxies (NGINX, Cloudflare, AWS ALB) that terminate TLS and forward requests to the backend. Administrators sometimes configure rate limiting to key on the X-Forwarded-For header instead of the actual upstream IP. An attacker can simply send X-Forwarded-For: 10.0.0.1, then X-Forwarded-For: 10.0.0.2, and so on, resetting the rate limit counter with every request. This is known as "rate limit header spoofing" when the upstream proxy does not strip or trust the correct header.
The sandbox below simulates a login form protected by a rate limiter. Use the controls to toggle IP rotation, X-Forwarded-For spoofing, or wait for the rate limit to reset. Watch how real attackers bypass your defences.
In 2019, Instagram suffered a massive credential-stuffing campaign. Attackers used password lists from previous data breaches — Linkedin, MySpace, and others — and attempted to log into Instagram accounts. The attackers routed traffic through residential proxy networks, including services like Luminati (now Bright Data), which provided access to millions of real home IP addresses. Each IP made only a handful of attempts, staying well under Instagram's per-IP rate limits.
Instagram detected unusual patterns — many logins from residential IPs concentrated on specific accounts — but the distributed nature of the attack made IP-based blocking ineffective. Instagram eventually introduced account-level rate limiting (limiting attempts per specific username regardless of source IP) and forced password reset notifications for affected accounts. The incident highlighted that per-IP rate limiting alone is insufficient against attackers with access to large proxy networks.
Effective rate limiting requires multiple layers that address different bypass techniques. No single layer is sufficient.
// VULNERABLE — only per-IP rate limiting
const limiter = rateLimit({ windowMs: 60000, max: 5 });
app.use('/api/login', limiter);
// SAFE — multi-layered approach
// Layer 1: Per-account rate limit (across all IPs)
const accountLimiter = rateLimit({
keyGenerator: (req) => req.body.username,
windowMs: 60000,
max: 10,
});
// Layer 2: Per-IP rate limit (stops single-source attacks)
const ipLimiter = rateLimit({
keyGenerator: (req) => req.ip,
windowMs: 60000,
max: 5,
});
// Layer 3: Validate X-Forwarded-For against trusted proxy
app.set('trust proxy', 1); // only trust first proxy
// Layer 4: CAPTCHA after N failed attempts per account
app.post('/api/login', accountLimiter, ipLimiter, async (req, res) => {
const attempts = await redis.get(`login:${req.body.username}`);
if (attempts > 3) {
// require CAPTCHA for subsequent attempts
}
});Additional layers: use in-memory or Redis-backed counters for sub-millisecond latency; implement exponential backoff after successive failures; monitor for race conditions by accepting a small burst window (sliding window log rather than fixed window); and fall back to CAPTCHA or account lockout when anomaly thresholds are exceeded. For API endpoints, require API keys and enforce per-key limits independently of IP.
1.Which rate limiting bypass technique uses a large pool of distinct IP addresses to stay under per-IP thresholds?
2.How does an attacker exploit the X-Forwarded-For header to bypass rate limiting?
3.What is the most effective defence against distributed credential stuffing using residential proxies?