Peakhour.IO - Rate Limiting

The IP Changed. Did the Actor?

2026-08-01T11:20:00+10:00

An attacker can change an IP address faster than most teams can change a rule.

Residential proxy services make that rotation routine. A client can send one request through a household connection in Sydney, the next through a mobile network in Melbourne, and another through an address that has never appeared in a reputation feed. An IP-only counter sees three quiet sources. The application may still be dealing with one operator and one campaign.

The tempting response is to find a replacement identifier. There is no universal one.

Network fingerprints, browser attributes, cookies, accounts, API keys, timing, and route sequences can all help correlate requests. Each can also be shared, copied, cleared, or changed. The practical goal is not to prove a person. It is to keep enough continuity to control a specific behaviour.

Ask What Stayed the Same

When addresses rotate, look for continuity in the work being attempted:

the same account or set of accounts;
a repeated username or credential corpus;
one API token, tenant, or application identifier;
a stable TLS or HTTP fingerprint cohort;
the same route sequence and parameter shape;
similar timing, retries, and failure outcomes;
a narrow set of ASNs, countries, or network categories;
consistent application cost or object enumeration.

One field may be weak. Several observations agreeing can support a bounded action.

Google's IPIDEA investigation described shared residential proxy infrastructure supplied through multiple SDK brands and reseller arrangements. That is useful context for defenders: provider names and exit addresses can change while the commercial path behind them remains connected.

Fingerprints Group Clients; They Do Not Name Them

A TLS fingerprint can reveal that connections share a normalised handshake shape. It cannot establish that they came from the same person, device, or process.

This distinction matters because popular browsers create large cohorts. Attack tools can also imitate common handshakes. Our article A Network Fingerprint Is a Cohort, Not a Client covers the boundary in detail.

Use a versioned fingerprint as one grouping key:

method + version + value + capture point

Then join it to the route and outcome. A common fingerprint that submits one successful login is uninteresting. The same cohort trying passwords against thousands of accounts through rotating residential networks is operationally useful.

Fingerprint provenance matters as much here as it does in API protection. At an origin behind a CDN, the visible connection may be the CDN hop. Only compare values captured at equivalent, trusted points.

Build Counters Around the Abuse

Peakhour Advanced Rate Limiting can use route, headers, ASN, country, IP, TLS fingerprint, response code, and bot state as concrete inputs. The right key depends on what needs protection.

For credential stuffing:

account + failed outcome
fingerprint cohort + login route + failed outcome

For scraping:

fingerprint cohort + resource family
API credential + operation + cost class

For account creation:

device cohort + signup route + verification outcome

Use more than one counter when the abuse can move between dimensions. A per-account limit protects one user. A cohort-wide limit sees distribution across accounts. A per-IP limit still catches crude bursts. No single key has to solve the campaign.

Avoid the opposite error: a key so broad that it turns a shared mobile SDK or current browser release into one actor. Before enforcement, inspect bucket sizes and successful outcomes. If one cohort contains a material part of normal traffic, it is an observation key, not a direct blocking key.

Route Sequence Can Carry Continuity

Automation often performs the same steps even when its network changes.

A normal account session might load a page, obtain a token, submit one credential, establish a session, and continue to an expected destination. A distributed credential campaign may call the login endpoint directly, repeat a narrow header set, receive the same failure, change the account, and start again.

The individual requests are small. The sequence exposes the job.

Keep this evidence purpose-bound. A security control does not need to build a permanent profile of a person. It needs enough recent history to decide whether a sensitive route is being used as intended. Our Account Security Without Tracking People explains that privacy boundary.

Expect the Actor to Adapt

Once a counter begins to work, the traffic will change. The operator may randomise headers, switch browser versions, slow the cadence, distribute accounts across more cohorts, or move to another route.

That does not make the original control a failure. It means the campaign has paid an adaptation cost. Keep the decision record so the next change is visible:

policy revision and activation time;
key dimensions and thresholds;
allowed, limited, challenged, and blocked counts;
successful business outcomes;
origin and application cost;
new cohorts and routes after enforcement.

Set an expiry or review date. Fingerprint populations and browser versions drift. Emergency rules should not survive their evidence by default.

Continuity Is a Working Hypothesis

The honest question is not “did we identify the actor?” It is “do these requests share enough evidence that one control should count them together?”

That wording leaves room for uncertainty. It also produces a policy an operator can test.

Start with one abused route. Compare IP-only counters with a small number of composite candidates. Observe bucket size, legitimate completion, failed outcomes, and origin cost. Apply a reversible action to the key that separates the behaviour without turning a common client cohort into collateral damage.

The IP will change. A well-built control follows the work, not the address.

Beyond the IP Address

2025-09-01T00:00:00+10:00

For years, rate limiting has been a standard control for protecting websites and APIs from abuse. The basic model is simple: limit the number of requests a single "user" can make in a given period. If a user exceeds the limit (e.g., 10 login attempts in a minute), they are temporarily blocked.

The hard part has always been identifying that "user". Traditionally, the answer was the IP address. The assumption was that one IP address equaled one user. In the early days of the internet, this was a reasonable approximation. Today, that assumption no longer holds, and it leaves systems exposed to modern attacks.

The IP address is no longer a reliable identifier for a single user or device. There are three common reasons:

Proxy Networks: Attackers don't use a single IP address. They use large residential proxy networks to rotate requests through thousands or even millions of different IP addresses, making each request look like it comes from a new user.
Shared IPs (CGNAT): At the same time, a single IP address can represent thousands of legitimate users. Mobile carriers use Carrier-Grade NAT (CGNAT) to make many mobile devices share the same public IP. Similarly, an entire office building or university campus might appear to the internet as a single IP.
Distributed Attacks: Modern automated attacks, like Layer 7 DDoS or credential stuffing, are inherently distributed. Attackers use botnets or proxy networks to spread their attack across a large number of IPs, so no single IP ever exceeds a traditional rate limit.

Blocking a shared IP because of one bad actor can cause collateral damage, denying access to thousands of legitimate users. On the other side, failing to see that thousands of IPs are part of a single coordinated attack means the attack succeeds. Traditional IP-based rate limiting is no longer enough.

The New Way: Advanced Rate Limiting

Advanced Rate Limiting addresses this by moving beyond the IP address. Instead of grouping requests by a single, unreliable identifier, it lets you count requests using more stable and meaningful characteristics of the connection or the software making it.

This approach groups requests using identifiers like:

TLS/HTTP2 Fingerprints: Every client application (like a browser or a script) has a unique "fingerprint" based on how it initiates a secure connection (TLS) or communicates over HTTP/2. This fingerprint remains consistent even as an attacker rotates through thousands of IP addresses. By rate limiting based on the TLS fingerprint, you can track and block the underlying automation tool itself, not just the IPs it uses.
Device Characteristics: A fingerprint can be constructed from a range of attributes, including the device's operating system, browser version, and more. This allows for the detection of repeated requests coming from the same class of device.
A Combination of Headers: For authenticated APIs, you can group requests by an Authorization header or API key, enforcing fair usage and preventing abuse by a single authenticated client.

Practical Use Cases

The value of advanced rate limiting is clearest when it is applied to real-world threats:

Mitigating Distributed Credential Stuffing: An attacker using a tool like OpenBullet launches a credential stuffing attack against your login page, rotating through thousands of residential proxy IPs. Traditional rate limiting is ineffective here. However, the OpenBullet software has a consistent TLS fingerprint. By setting a rule to limit failed login attempts per TLS fingerprint, you can detect and block the entire distributed attack, regardless of how many IPs are involved.
Protecting APIs from Abuse: A partner is abusing their API key, sending far too many requests and degrading service for other users. By rate limiting based on the Authorization header, you can enforce usage limits on a per-client basis, keeping access fair without affecting other users.
Stopping Content Scrapers: A scraper is hammering your e-commerce site to steal pricing data. They are using a botnet to distribute the requests across hundreds of IPs. However, the scraping script has a unique combination of a user-agent and a TLS fingerprint. Advanced rate limiting can count requests based on this combined signature and block the scraper, protecting your intellectual property.

When attackers are distributed, your defences need to see the single actor behind the many IPs. Advanced rate limiting provides that visibility and should be part of a modern application security strategy.