When the Traffic Looked Legitimate Until It Wasn't
A financial services company running a public-facing REST API noticed something unusual in their access logs during a routine Tuesday morning review. Thousands of authentication requests had arrived overnight, each one spaced exactly 900 milliseconds apart, originating from dozens of residential IP addresses spread across five countries. The requests never triggered a single rate limit alert. Each individual IP stayed well within the configured threshold of 100 requests per minute. The aggregate effect was a sustained credential stuffing campaign that ran for six hours before a human analyst spotted the pattern.
This is the core problem with rate limiting in 2026: the strategy that worked when attackers sent floods of traffic from single sources breaks down entirely when attackers distribute load across hundreds of endpoints. With DDoS malware families like WSzero already on their fourth documented version and actively incorporating multi-vector distribution techniques, the assumption that rate limiting alone catches abuse has become operationally dangerous. This article covers how modern rate limiting strategies work, where they fail under real adversarial conditions, and what implementation decisions actually make a difference.
What Rate Limiting Is Actually Protecting Against
Rate limiting sits at the intersection of availability protection and abuse prevention. It serves different purposes depending on where you deploy it and what traffic you're examining. Before choosing an algorithm, security teams need to be honest about what threat they're actually trying to counter.
At the API gateway level, rate limiting protects backend infrastructure from being overwhelmed. At the authentication endpoint level, it slows credential stuffing and brute force attacks. At the business logic level, it prevents scraping, price enumeration, and account takeover probing. Each of these scenarios requires different thresholds, different identifiers, and different responses when limits are breached.
The mistake most teams make is deploying a single rate limiting configuration across all endpoints and treating it as a solved problem. When Meta's AI support bot was abused to facilitate Instagram account takeovers, the attack succeeded in part because the rate limiting protecting the AI interaction layer was calibrated for availability, not abuse prevention. The requests looked like normal user behavior in terms of volume; the abuse was in the payload and the downstream action triggered.
The Four Core Algorithms and Their Real Tradeoffs
Fixed Window Counting
Fixed window counting is the simplest implementation: count requests within a defined time window, reject any that exceed the threshold, reset the counter at the window boundary. A limit of 100 requests per minute means the counter increments with each request and resets at the top of each minute.
The vulnerability here is the boundary condition. An attacker can send 100 requests in the last second of one window and 100 requests in the first second of the next window, effectively hitting your endpoint with 200 requests in a two-second span without triggering any limit. This boundary exploitation is well understood and trivially scriptable. Fixed window counting is appropriate for coarse-grained API tier enforcement where the cost of a boundary burst is low. It should not be used to protect authentication endpoints or any endpoint where a short burst causes direct harm.
Sliding Window Log
The sliding window log algorithm stores a timestamp for every request and evaluates the count of requests within a rolling time window ending at the current moment. When a new request arrives, the system discards timestamps older than the window duration, counts remaining entries, and either allows or rejects the request.
This approach eliminates the boundary exploitation problem entirely. The tradeoff is memory: storing per-request timestamps for every client becomes expensive at scale. A high-traffic API receiving millions of requests per hour from thousands of distinct clients will burn significant Redis memory maintaining these logs. For most production deployments, this algorithm is reserved for sensitive endpoints like login, password reset, and payment initiation where precision justifies the memory cost.
Sliding Window Counter
The sliding window counter is a practical middle ground. It maintains counts for the current fixed window and the previous fixed window, then calculates an estimated rate by weighting the previous window's count based on how far the current moment sits within the current window.
If the window is one minute and you're 45 seconds into the current window, the algorithm calculates: (previous_count × 0.25) + current_count. This approximation smooths the boundary burst problem without storing per-request timestamps. The estimate has a small margin of error, typically within a few percent of the true sliding window count, which is acceptable for most rate limiting use cases outside of high-precision abuse detection.
Token Bucket and Leaky Bucket
Token bucket algorithms maintain a bucket that fills at a fixed rate up to a maximum capacity. Each request consumes one or more tokens. When the bucket is empty, requests are rejected. This model allows controlled bursting: a client can accumulate tokens during idle periods and spend them during a brief burst, which aligns with how legitimate applications actually behave.
The leaky bucket model processes requests at a fixed output rate regardless of input rate, effectively queuing or dropping excess traffic. It produces very smooth traffic at the cost of introducing latency for burst scenarios, which makes it better suited for egress rate limiting than for inbound API protection.
Token bucket is the right default for general API rate limiting because it mirrors realistic usage patterns. A mobile app that wakes from background state and makes several rapid API calls is a normal client, not an attacker. Fixed limits that reject legitimate bursts generate false positives and user-facing errors. Token bucket handles this gracefully while still capping sustained high-volume abuse.
Identifier Selection and Why IP Address Alone Fails
The credential stuffing campaign described at the opening of this article failed to trigger rate limits because the rate limiter used IP address as its only identifier. This is the most common configuration mistake in API rate limiting, and it is the one attackers exploit first.
Residential proxy networks and compromised device pools give attackers access to thousands of distinct IP addresses. The WSzero DDoS botnet family, now on its fourth version with 21 documented propagation vulnerabilities, specifically builds distributed attack infrastructure designed to stay under per-IP thresholds. When a threat actor needs to send 10,000 credential pairs against a login endpoint, distributing across 1,000 IP addresses at 10 requests each is trivial.
Effective rate limiting uses multiple identifier layers:
- IP address: Still useful for catching unsophisticated attacks and as one signal among many. Use it as a fast-path block for known-bad ranges, but not as the sole rate limiting identifier.
- User account identifier: Rate limiting against a specific username or account ID catches distributed attacks targeting a single victim account. Ten failed login attempts for [email protected] from ten different IP addresses should still trigger a limit on that account.
- Device fingerprint: Browser fingerprinting, TLS fingerprinting, or mobile SDK device identifiers catch attackers rotating IPs while using the same client. Many credential stuffing tools generate distinctive fingerprints that persist across IP rotations.
- API key or session token: For authenticated endpoints, the API key is a better primary identifier than IP address because it directly identifies the consuming application or user.
- Endpoint-specific compound identifiers: Combining IP address with username for login endpoints catches both single-source attacks against many accounts and distributed attacks against one account.
Configuring Thresholds That Match Real Attack Behavior
Threshold selection is where most rate limiting configurations fail operationally. Teams either set limits too high because they fear false positives, or set them too low and generate noise that trains responders to ignore alerts.
Start with baseline measurement. Run your API in monitoring mode for two to four weeks, logging request rates per identifier across all endpoints. Calculate the 99th percentile request rate for legitimate traffic. Your rate limit should sit comfortably above that 99th percentile for normal operations and well below the minimum volume needed to cause harm.
For authentication endpoints specifically, research on credential stuffing operations shows that most commercial stuffing tools are configured to send between 0.5 and 2 requests per second per IP to evade detection. A threshold of 10 login attempts per minute per account from any source is already aggressive from the attacker's perspective. Legitimate users who forget their password and retry a handful of times never hit that threshold. An automated tool hitting the same account from rotating IPs will trigger it within seconds.
For general API endpoints, consider the business logic. A product search endpoint at an e-commerce company might legitimately receive 30 requests per minute from a power user browsing aggressively. That same endpoint should never receive 3,000 requests per minute from a single session, which is a scraping indicator. Set thresholds that create real friction for automated abuse without breaking the legitimate use case.
Where to Enforce Rate Limits in Your Architecture
Rate limiting can be enforced at multiple layers: the CDN edge, the API gateway, the application server, or the service mesh. Each position has different visibility and different tradeoffs.
CDN and Edge Enforcement
Enforcing rate limits at the CDN edge stops volumetric attacks before they reach your infrastructure. Providers like Cloudflare, Fastly, and AWS CloudFront support configurable rate limiting rules. The advantage is that malicious traffic is dropped close to the source, reducing infrastructure load. The disadvantage is that CDN-level rate limiting typically operates on IP address only and has limited visibility into application-layer context like user identity or session state.
CDN rate limiting is the right first layer for DDoS mitigation and broad volumetric abuse. It should not be your only layer for API-specific abuse prevention.
API Gateway Enforcement
API gateways like Kong, AWS API Gateway, Apigee, and nginx with Lua modules can enforce rate limits with richer context: API key, user identity pulled from JWT claims, endpoint path, and request attributes. This is the right enforcement point for tiered rate limiting by customer plan, per-user authentication throttling, and endpoint-specific policies.
Redis-backed distributed rate limiting is the standard implementation here. Each gateway instance reads and writes a shared Redis counter, ensuring that limits apply consistently across a horizontally scaled gateway cluster. Without shared state, a client can bypass per-instance limits by distributing requests across instances.
Application-Layer Enforcement
Application-level rate limiting is appropriate when the limit logic depends on business context that only the application understands: account status, subscription tier, geographic risk signals, or behavioral anomaly scores. Libraries like django-ratelimit, rack-attack, and express-rate-limit provide middleware-level enforcement with access to the full request context.
The risk of application-level enforcement is that it runs after the request has consumed network and gateway resources. For high-volume attacks, apply coarse limits at the edge and reserve application-layer enforcement for fine-grained business logic protection.
Dynamic Rate Limiting and Behavioral Signals
Static rate limits treat all traffic within the threshold as equally acceptable. Dynamic rate limiting adjusts thresholds based on behavioral signals observed during the request lifecycle, creating a tighter net around suspicious patterns without increasing false positives on legitimate traffic.
Consider an authentication endpoint. Under static rate limiting, a client that sends exactly nine failed logins per minute per account (just below a threshold of ten) will never be blocked. Under dynamic rate limiting, the system tracks the ratio of failed to successful authentications, the velocity of new accounts being targeted, and the diversity of passwords being attempted. A client consistently failing 8-9 times per minute against a rotating list of accounts triggers escalating restrictions even before hitting the static threshold.
Implementing dynamic rate limiting requires a decision engine beyond a simple counter. The approach used in practice combines the base rate limiter with a risk scoring function: requests with risk scores above a threshold receive tighter per-identifier limits applied in real time. Risk signals that work well in production include:
- Authentication failure rate over a rolling window
- Number of distinct accounts targeted from a session or IP
- Password reuse patterns across accounts
- Request timing regularity (automated tools are often too precise)
- User agent and TLS fingerprint consistency
Response Actions Beyond a 429 Status Code
Returning HTTP 429 Too Many Requests is the standard response to a rate limit breach, but it is also a signal to the attacker that confirms the limit exists and reveals its structure. Sophisticated attackers use 429 responses to calibrate their sending rate to stay just below the threshold.
Silent rate limiting, also called shadow limiting or tarpitting, is a more effective response for confirmed abuse. Instead of returning 429, the server returns 200 with empty or degraded results, introduces artificial latency, or returns plausible-looking fake data. From the attacker's perspective, their tool appears to be working while actually accomplishing nothing. This wastes their time and resources without revealing the defensive mechanism.
For confirmed malicious actors, the response should escalate beyond rate limiting to IP-level blocking, account lockout, CAPTCHA challenges, or human review queues. Rate limiting is a detection and friction mechanism; remediation requires additional enforcement layers.
Log all rate limit events with full request context: timestamp, identifier, endpoint, request count at time of limit, user agent, TLS fingerprint, and any available application context. These logs feed threat intelligence workflows and help identify campaigns that span multiple targeted accounts or services. With cybersecurity firms now being targeted by fraudulent organizational invites and social engineering campaigns like those impersonating OpenAI, cross-service attack correlation from rate limit logs has identified early-stage reconnaissance activity before attackers escalate to their primary objective.
Testing Your Rate Limiting Configuration Before Attackers Test It For You
Rate limiting configuration errors are common and typically silent until an attack reveals them. A misconfigured Redis cluster that loses shared state causes rate limits to apply per-instance rather than globally, multiplying effective thresholds by the number of gateway nodes. A misconfigured window boundary creates exploitable timing gaps. An identifier extraction bug causes limits to apply to the wrong key.
Build rate limit validation into your API testing pipeline. For each endpoint with a configured limit, automated tests should:
- Confirm that requests at the limit threshold succeed
- Confirm that requests exceeding the threshold return the expected status code or are silently dropped per policy
- Confirm that limits reset correctly after the window expires
- Confirm that per-account limits apply correctly regardless of source IP
- Confirm that distributed state is consistent across multiple gateway instances under concurrent load
Run these tests against staging before each deployment and schedule periodic testing in production using a controlled traffic source. Rate limiting configuration drifts as APIs evolve: new endpoints get added without inheriting rate limit policies, refactoring changes identifier extraction logic, and gateway upgrades reset configuration to defaults.
Operational Integration and Alert Routing
Rate limiting generates operational signals that most teams underuse. When a rate limit fires, it means automated tooling is targeting that endpoint. This is worth investigating, not just incrementing a dashboard counter.
Route rate limit alerts to your security operations workflow when specific conditions are met: sustained limit breaches over more than five minutes, breach of per-account authentication limits (which indicate targeted account attacks), rate limit events from IPs with existing threat intelligence matches, and rate limit events correlated across multiple endpoints from the same identifier (indicating systematic API enumeration).
The CISA advisory requiring urgent remediation of actively exploited Cisco vulnerabilities is a reminder that attackers move quickly once they identify a viable target. Rate limit telemetry that sits unreviewed in a SIEM dashboard does not contribute to defense. Teams that route rate limit signals into active investigation workflows catch campaigns in their reconnaissance phase rather than their execution phase.
Integrate rate limit event data with your threat intelligence platform. An IP that triggers rate limits on your API today may be present in shared threat feeds by tomorrow. Conversely, IPs already flagged in threat intelligence feeds that appear in your rate limit logs should receive immediate attention rather than waiting for a threshold breach.
What Practical Deployment Actually Requires
Implementing effective rate limiting across a real production API surface requires accepting that it is an ongoing configuration problem, not a one-time setup task. Attacker tooling evolves. DDoS botnet families like WSzero that have reached a fourth version with expanded vulnerability propagation demonstrate that adversaries actively iterate to defeat existing controls.
The teams that maintain effective rate limiting share a few operational practices: they baseline legitimate traffic before setting thresholds, they use multiple identifier layers rather than IP address alone, they test rate limiting configuration automatically as part of deployment pipelines, they route rate limit signals into security investigation workflows, and they treat rate limiting as one layer of a defense-in-depth approach rather than a standalone control.
Rate limiting does not replace anomaly detection, threat intelligence integration, or behavioral analysis. It creates friction that slows automated abuse, generates signals that feed detection workflows, and buys time for human responders to identify and respond to campaigns. Its effectiveness depends entirely on how thoughtfully it is configured and how actively its signals are used.
