When State-Sponsored Actors Probe API Surfaces Methodically
The CL-STA-1062 campaign targeting Southeast Asian governments and critical infrastructure offers a concrete lesson that many API security teams miss: sophisticated threat actors do not hammer endpoints until alarms fire. They probe slowly, rotate infrastructure, and exploit the seams between detection thresholds. Rate limiting, when configured thoughtfully, is one of the most effective controls available to slow this kind of reconnaissance. When it is configured carelessly, it becomes a boundary attackers map and then route around.
Campaigns like CL-STA-1062 rely on sustained, low-volume access to government APIs to enumerate accounts, extract session tokens, and stage lateral movement. The same methodology surfaces in large-scale credential attacks documented in recent threat briefs, where attackers distribute authentication attempts across thousands of IP addresses to stay under per-IP thresholds. For cybersecurity professionals and IT administrators responsible for API infrastructure, the question is not whether rate limiting matters. The question is which rate limiting strategy holds under real adversarial pressure.
This article walks through rate limiting architectures from first principles, covers the practical tradeoffs between approaches, and addresses the implementation pitfalls that leave teams exposed even after controls are in place.
Why Rate Limiting Is a Threat Mitigation Control, Not Just an Infrastructure Concern
Rate limiting is frequently treated as a traffic management tool, something operations teams tune to prevent backend overload. That framing underestimates its role in the security stack. At its core, rate limiting constrains the speed at which an attacker can interact with your API surface. It does not stop a determined adversary, but it raises the cost of automation and forces behavioral changes that detection systems can observe.
Consider a credential stuffing campaign. An attacker with a list of 500,000 username-password pairs needs to submit those pairs to your authentication endpoint. Without rate limiting, they can do this in minutes. With aggressive rate limiting, the same operation might take days or weeks, during which detection systems have more opportunities to identify the pattern, IP reputation feeds have time to flag source infrastructure, and the attacker's operational window shrinks. The recent Threat Brief on large-scale credential attacks documents exactly this dynamic: attackers who previously relied on speed are now distributing across botnets and residential proxies specifically because defenders have deployed rate limiting that punishes concentrated volume.
Rate limiting also has direct relevance to the ransomware campaigns using social engineering to target small businesses. APIs that support file sharing, authentication, or payment processing in SMB environments are often the least hardened. When the ScreenConnect campaign documented in recent SOC reports used legitimate remote access tooling as a vector, APIs exposed to external automation were among the first surfaces probed for weakness. Rate limiting those surfaces reduces the automation surface attackers can exploit before detection occurs.
The Four Core Rate Limiting Algorithms
Understanding the algorithmic differences between rate limiting strategies is essential for matching the right approach to the threat model. Each algorithm has distinct behavior under adversarial conditions.
Fixed Window Counters
Fixed window rate limiting divides time into discrete intervals and counts requests per interval. An implementation might allow 100 requests per minute per IP address. When the counter reaches 100, subsequent requests are rejected until the window resets.
The practical weakness is the boundary condition. An attacker who understands your window duration can send 100 requests at the end of one window and 100 at the start of the next, achieving 200 requests in a two-second span without triggering a limit. This is not theoretical. Automated tooling routinely exploits window boundaries in fixed counter implementations.
Fixed window counters are appropriate for coarse traffic management where precision is less critical than implementation simplicity. They are a poor choice for authentication endpoints or any API where burst exploitation creates meaningful risk.
Sliding Window Log
Sliding window logging maintains a timestamped record of every request within the defined window period. When a new request arrives, the system checks how many requests occurred within the past window duration, counts only those, and compares against the limit.
This approach eliminates the boundary condition problem. A window of 100 requests per 60 seconds is enforced precisely regardless of when within that 60 seconds the requests arrive. The tradeoff is memory consumption. For high-traffic APIs, storing per-client request timestamps at scale requires careful infrastructure planning, particularly when sliding windows are enforced per user, per endpoint, or across multiple dimensions simultaneously.
Redis sorted sets are a common implementation vehicle. Each client key maps to a sorted set of timestamps. On each request, the system removes expired timestamps, counts remaining entries, and conditionally adds the new timestamp or rejects the request. This works well in distributed environments because Redis operations are atomic, preventing race conditions that can defeat rate limiting in multi-instance deployments.
Sliding Window Counter (Approximate)
The approximate sliding window counter blends the memory efficiency of fixed windows with the precision of sliding window logs. It maintains counters for the current and previous windows, then calculates an approximate request count using a weighted sum based on how far into the current window the request falls.
For example, if the previous window saw 80 requests, the current window has seen 30 requests, and the current timestamp is 40% through the current window, the approximate count is (80 × 0.6) + 30 = 78. This approach uses constant memory per client regardless of request volume and introduces only small estimation errors in exchange for significant resource efficiency at scale.
For most production API rate limiting scenarios, the approximate sliding window counter hits the right balance between accuracy and operational cost. It handles adversarial timing exploits better than fixed windows while avoiding the memory overhead of full timestamp logs.
Token Bucket and Leaky Bucket
Token bucket algorithms model rate limiting as a bucket that fills with tokens at a fixed rate up to a maximum capacity. Each request consumes one or more tokens. If the bucket is empty, the request is rejected or queued. This allows controlled bursting: a client who has been idle can consume accumulated tokens in a short burst, then must wait for the bucket to refill.
Leaky bucket algorithms invert this model. Requests enter a queue and drain at a fixed rate regardless of input timing. This enforces a smooth output rate but does not tolerate legitimate burst traffic gracefully, which makes it more appropriate for queue-driven architectures than synchronous API enforcement.
Token buckets are particularly relevant for APIs that serve legitimate clients with bursty access patterns. A mobile application that syncs data when a user opens it generates a burst of requests, then goes quiet. A token bucket allows this while still preventing sustained high-volume abuse. The key parameter is the refill rate relative to the bucket capacity. A bucket capacity of 20 tokens with a refill rate of 2 tokens per second allows a burst of 20 requests followed by a sustained rate of 120 requests per minute, a pattern most legitimate clients fit comfortably while most automated abuse does not.
Dimensions of Rate Limiting: What You Are Actually Counting
Algorithm selection is only part of the decision. The dimension along which you count requests determines whether your rate limiting actually constrains adversarial behavior or just inconveniences legitimate users.
Per-IP Rate Limiting
Per-IP rate limiting is the most common starting point and the most easily defeated by modern attackers. Distributed botnets, residential proxy networks, and cloud infrastructure rotation all allow attackers to spread requests across enough distinct IP addresses to stay under per-IP thresholds. The CL-STA-1062 campaign used exactly this kind of infrastructure distribution to avoid triggering IP-based detection systems against government targets.
Per-IP limits remain useful as a baseline control and as a signal source. A single IP approaching or hitting its rate limit is a detection signal even if it is not a block. Aggregating those signals across IP ranges, ASNs, or geographic regions can reveal distributed campaigns that no individual IP-level limit would catch.
Per-User and Per-Token Rate Limiting
For authenticated APIs, per-user or per-API-token rate limiting is more robust than per-IP controls. It ties limits to the identity making requests rather than the network address, which makes IP rotation ineffective. An attacker who has compromised one user account cannot accelerate their access by rotating source IPs if the rate limit follows the user identity.
The practical complication is that per-user limits require the rate limiting layer to have access to authenticated identity, which typically means applying limits after authentication rather than before. For authentication endpoints themselves, per-user limits are not available because the user is not yet authenticated. This is where per-IP and per-user strategies must layer.
Per-Endpoint Rate Limiting
Different endpoints carry different risk profiles. Authentication endpoints, password reset flows, and account enumeration-prone user lookup endpoints warrant tighter limits than static asset delivery or low-sensitivity read endpoints. Applying uniform limits across an entire API is a mistake that either over-restricts legitimate use of low-risk endpoints or under-restricts high-risk ones.
A practical configuration might apply limits of 5 requests per minute per IP to authentication endpoints, 30 requests per minute per authenticated user to search endpoints, and 300 requests per minute per token to bulk data export endpoints with additional anomaly monitoring on volume spikes. These numbers are illustrative; appropriate limits depend on legitimate usage patterns established through baseline measurement before controls are deployed.
Global and Tenant-Level Rate Limiting
In multi-tenant API environments, a single large tenant generating legitimate high volume can exhaust global rate limits, creating denial-of-service conditions for other tenants. Conversely, a compromised tenant account conducting automated abuse can consume resources allocated to others. Tenant-level rate limiting with individual quotas addresses both failure modes.
Global rate limits set absolute ceilings that protect backend infrastructure. Tenant limits allocate fair shares within that ceiling. Per-endpoint and per-user limits within tenant quotas provide the most granular protection. Layering these dimensions creates a defense-in-depth model for rate limiting that is substantially harder for attackers to exploit than any single-dimension approach.
Rate Limiting Checklist for Production API Environments
The following checklist reflects controls and configurations that cybersecurity professionals should verify before treating a rate limiting deployment as production-ready against adversarial traffic.
- Authentication endpoints have strict, independent limits. Login, registration, password reset, and MFA challenge endpoints have tighter limits than all other API surfaces, applied both per-IP and per-user where applicable.
- Rate limiting is enforced at the edge, not only at the application layer. Edge enforcement via API gateway, CDN, or load balancer prevents rejected traffic from consuming application server resources and allows enforcement before requests reach backend systems.
- Distributed rate limiting state is synchronized. In multi-instance deployments, rate limit counters are stored in a shared data store (Redis or equivalent) so that rotating between backend instances does not reset limits.
- Rate limit events generate security telemetry. Rate limit rejections are logged with full request context (IP, user agent, endpoint, timestamp) and forwarded to SIEM or security analytics for pattern detection. Volume and distribution of rate limit hits are treated as threat intelligence signals.
- Limits are calibrated against measured legitimate traffic baselines. Limits are set based on observed 99th percentile legitimate usage, not guesses, to minimize false positives that block real users.
- Responses to rate-limited requests are standardized and non-informative. Rate limit responses return HTTP 429 with a Retry-After header, and do not reveal information about threshold values or window durations that would help attackers calibrate their attack rate.
- Progressive penalties are implemented for persistent violators. Clients that repeatedly hit rate limits face escalating response times or extended lockout periods rather than a fixed per-request rejection, which raises the cost of sustained low-and-slow attacks.
- Bypass paths through the API are identified and covered. Mobile application endpoints, internal microservice APIs, partner integration endpoints, and legacy API versions are all included in rate limiting policy, not just the primary public API surface.
- Rate limiting interacts correctly with legitimate retry logic. Client SDKs and integration partners implement exponential backoff. Rate limiting configuration accounts for retry storms that follow outages.
- Token bucket capacity and refill rates are reviewed against current abuse patterns quarterly. Limits set at deployment drift out of alignment with both legitimate growth and evolving attack methodology if never revisited.
Behavioral Rate Limiting: Moving Beyond Simple Counters
Standard rate limiting counts requests. Behavioral rate limiting counts meaningful events. The distinction matters when attackers operate below numeric thresholds by spreading volume across time or IP space.
Behavioral rate limiting adds dimensionality by tracking sequences of actions rather than individual request volumes. An attacker conducting account enumeration against a user lookup endpoint might submit requests that each individually return 404, never hitting a per-IP request limit. A behavioral rate limiting layer that tracks the ratio of 404 responses to successful responses per IP per time window can detect this pattern even when raw request volume is low.
Similarly, behavioral controls can track failed authentication attempts across multiple accounts originating from the same ASN, the same user agent fingerprint, or the same TLS fingerprint. The Interpol-impersonating ransomware campaign documented in recent reporting used social engineering delivered through legitimate-looking infrastructure, where behavioral signals such as high outbound link click rates or unusual account access sequences following email delivery provided detection opportunities that volume-based controls missed entirely.
Implementation options for behavioral rate limiting include API gateway plugins that support custom request matching logic, WAF rules that track session-level error patterns, and SIEM-driven dynamic blocklisting that feeds enforcement decisions back to the edge based on behavioral analysis in near-real-time. The complexity overhead is higher than static counters, but for high-value API surfaces facing sophisticated threats, the investment is justified.
Rate Limiting in Context: Integration With Broader Security Controls
Rate limiting does not operate in isolation. Its effectiveness depends on how well it integrates with adjacent controls in the security stack.
IP reputation data amplifies rate limiting by allowing pre-emptive restriction of known-malicious infrastructure. An IP flagged in threat intelligence feeds as part of a credential-stuffing botnet can be subjected to more aggressive limits before it hits behavioral thresholds. This requires a mechanism for dynamically updating rate limiting rules based on threat feed inputs, which most mature API gateway products support through rule APIs or integration with threat intelligence platforms.
Device fingerprinting and TLS fingerprinting (JA3/JA3S) add a dimension that survives IP rotation. A bot framework that maintains consistent TLS client hello patterns will produce consistent fingerprints even across thousands of distinct source IPs. Rate limiting keyed on fingerprint rather than or in addition to IP address constrains this class of attacker more effectively. The BusySnake stealer campaign documented in Armored Likho reporting used consistent tooling signatures that would have been visible in TLS fingerprint data even when source infrastructure rotated.
CAPTCHA challenges and proof-of-work mechanisms serve as rate limiting extensions for browser-facing APIs. Rather than rejecting requests outright when limits are approached, presenting a computational or interactive challenge filters automated clients while preserving access for legitimate human users. This is particularly valuable for authentication flows where blocking legitimate users who have forgotten their password creates customer service burden and pressure to relax security controls.
Implementation Pitfalls That Leave Teams Exposed
Rate limiting deployments fail in predictable ways. Understanding these failure modes before deployment prevents the common outcome of security teams believing they have coverage that attackers have already circumvented.
Failing to Cover All API Versions and Surfaces
Production APIs accumulate legacy versions, mobile-specific endpoints, and internal endpoints that get exposed through misconfiguration. Rate limiting applied to the current public API version does not protect deprecated v1 endpoints that still accept traffic. Regular API inventory reviews are a prerequisite to effective rate limiting policy coverage. The ScreenConnect campaign documented in SOC reporting succeeded in part because legacy remote access interfaces operated outside the security controls applied to primary infrastructure.
Race Conditions in Distributed Enforcement
In horizontally scaled API deployments, rate limiting state stored in application memory is local to each instance. A client that distributes 10 requests across 10 instances can exceed a 5-requests-per-minute limit with no single instance triggering enforcement. Centralized state in Redis, Memcached, or equivalent shared storage is mandatory for distributed deployments. Atomic increment operations with expiry ensure counter accuracy without locking overhead.
Treating HTTP 429 as the Only Response Strategy
Immediate rejection communicates limit boundaries to attackers. An attacker who receives 429 responses knows their current rate. Soft throttling, introducing artificial latency rather than outright rejection, slows attackers without signaling exact thresholds. Returning synthetic success responses for clearly automated requests (tarpitting) can waste attacker resources and generate intelligence about attack tooling and payloads. These approaches require more sophisticated implementation but provide detection value beyond simple rejection.
Not Accounting for IPv6
Per-IP rate limiting calibrated for IPv4 single-address granularity fails catastrophically against IPv6. A /48 prefix provides over 65,000 /64 subnets, each with a practically unlimited number of valid host addresses. An attacker with a single IPv6 prefix can generate unique source addresses at will, defeating per-IP limits entirely. Rate limiting must account for IPv6 address blocks rather than individual addresses, and infrastructure should be configured to enforce limits at /48 or /64 prefix granularity rather than per individual IPv6 address.
Setting Limits Without Measuring Baselines First
Limits set too low create denial-of-service conditions for legitimate users. A mobile application that generates 50 authentication-adjacent requests during a complex onboarding flow will be broken by a 10-requests-per-minute limit regardless of whether the user is legitimate. Deploying rate limiting in observe-only mode for two to four weeks before enforcement, with limits set based on measured traffic percentiles, prevents false positive rates that cause business stakeholders to push back on security controls.
Static Configuration Against Dynamic Attack Methodology
Attackers adapt. A rate limit that effectively constrains a credential stuffing campaign using 1,000 source IPs becomes ineffective when the same campaign scales to 100,000 residential proxies. Rate limiting configurations require ongoing review against observed attack patterns, with quarterly at minimum and event-driven reassessment following significant attack campaigns. Watering hole attacks pushing ScanBox and similar keylogger campaigns use methodologies that evolve faster than static configurations can track without active maintenance.
Overlooking the Retry-After Header
RFC 6585 defines the 429 response and recommends including a Retry-After header indicating when the client may retry. Omitting this header causes legitimate clients using standard HTTP libraries to retry immediately, creating retry storms that amplify load exactly when the system is already under pressure. Including accurate Retry-After values allows legitimate clients to back off gracefully while attackers who ignore standard HTTP semantics continue to identify themselves through persistent retry behavior.
A Practical Starting Configuration for High-Risk Endpoints
For teams starting from scratch or hardening existing deployments, the following configuration parameters represent a defensible baseline for authentication endpoints facing active threat pressure. These should be adapted based on measured legitimate traffic patterns.
- Algorithm: Approximate sliding window counter stored in Redis with atomic increment and TTL-based expiry.
- Per-IP limit on authentication endpoints: 10 requests per 10-minute window. Progressive penalty: first violation results in 10-minute block, second violation in the same hour results in 60-minute block.
- Per-user limit on authentication endpoints: 5 failed authentication attempts per 15-minute window with account-level lockout and notification on threshold breach.
- IPv6 enforcement: limits applied at /64 prefix granularity with monitoring at /48 for distributed attacks across subnets.
- Rate limit telemetry: all 429 events, progressive penalty triggers, and per-user lockouts forwarded to SIEM with IP, user agent, endpoint, and timestamp fields indexed for correlation.
- Review cadence: configuration reviewed monthly during active threat campaigns and quarterly during baseline periods, with documented rationale for all limit values.
Connecting Rate Limiting to Incident Response Workflows
Rate limiting data has investigative value beyond its enforcement function. When an incident occurs, rate limit logs provide a timeline of pre-attack reconnaissance that often predates the incident itself by days or weeks. Teams investigating the early stages of a breach will frequently find that authentication endpoints were probed at rates just below enforcement thresholds for extended periods before a successful compromise.
Incorporating rate limit telemetry into SOC workflows means treating sustained near-threshold traffic as a threat intelligence signal requiring investigation, not just a metric. An IP address consistently submitting 9 requests per 10-minute window against an authentication endpoint with a 10-request limit is not a policy violation, but it is a behavioral indicator that warrants enrichment with IP reputation data, ASN context, and correlation against other signals in the environment.
For IT administrators in SMB environments who may lack dedicated SOC resources, this translates to configuring alerting on near-threshold patterns in whatever logging infrastructure is available, whether that is a SIEM, a cloud-native logging service, or even a scheduled log review process. The SMB cyber readiness challenge documented in recent industry reporting includes API rate limiting as a control gap in small business environments specifically because it requires ongoing operational attention, not just initial deployment.
Rate limiting is one of the clearest examples of a security control where the gap between deploying it and deploying it effectively is wide enough for campaigns like CL-STA-1062 to operate comfortably. Closing that gap requires algorithmic understanding, multi-dimensional enforcement, integration with detection workflows, and a maintenance cadence that keeps pace with attacker adaptation.
