Peakhour.IO

Neither Consent Nor an App-Store Ban Makes a Residential IP Direct

2026-08-03T11:00:00+10:00

LG can remove every residential proxy SDK from its television app store. That may protect households and make one source of proxy capacity harder to operate. It will not make the next residential IP arriving at a login page trustworthy.

The distinction is easy to lose in the argument over smart TV apps. Consent governs how a device joins a proxy network. App-store policy governs one way the software reaches that device. Neither tells a website whether the next request from that household connection originated inside the household.

That is the part security and fraud teams have to operate.

The App Store Had a Real Problem

Spur Intelligence Labs downloaded and inspected 6,038 LG webOS and Samsung Tizen app packages. It found confirmed residential proxy SDK fingerprints in 2,058 of them. More than 42% of the LG apps were affected.

The apps included games, screensavers and utilities. Some presented a choice between advertising and sharing the television's connection. Spur also found consent language saying that proxy activity could continue after the app closed.

LG's response was direct. The company told KrebsOnSecurity that developers must remove the residential proxy option from their webOS apps or have those apps suspended. It also said it would strengthen its evaluation of developer submissions.

That is a reasonable platform control. A television is shared household equipment, not a personal phone that one adult necessarily administers. A one-time prompt does not show that the person holding the remote owns the internet connection, understands persistent background operation or still remembers the decision months later.

Removing the SDK reduces that exposure. It does not turn residential traffic back into direct traffic.

Consent Describes Enrolment

A meaningful consent record can establish something important: an authorised person knowingly allowed a particular device and software version to share resources under a stated set of terms.

That is a higher standard than a buried clause or software installed without the device owner's knowledge. It should include a plain explanation, an affirmative choice, a visible participation state and a withdrawal path that actually removes the device from every pool receiving its capacity.

Even strong consent has a boundary. It does not show who later bought access to the connection. It does not prove that customer vetting worked, that destination restrictions held or that the request now reaching a website is harmless.

There are at least three relationships involved:

The device and network owner decides whether the connection may be shared.
The proxy provider decides which customers and uses it will permit.
The destination decides what a relayed request may do to an account, transaction or API.

Consent speaks to the first relationship. Provider controls speak to the second. Neither can make the third decision on the destination's behalf.

Consent can make the supply relationship consensual. It cannot make every request using that supply legitimate.

An App-Store Ban Describes Distribution

App stores can remove applications, reject updates and block known SDKs. Those actions matter because they can reduce supply, protect device owners and raise the cost of enrolling more endpoints.

The policies are not all the same. Amazon's Device and System Abuse Policy prohibits apps that facilitate proxy services to third parties. Google Play permits proxy services only when proxying is the app's primary, user-facing core purpose. LG has chosen to remove residential proxy functionality from webOS apps.

Each rule governs software distributed through that platform. None covers every route by which a household connection can become a proxy exit. Capacity can also come from software on phones and computers, applications obtained elsewhere, compromised routers, infected streaming devices and pre-installed software. Our investigation into how bandwidth sharing feeds residential proxy networks follows those supply paths separately.

A store can close its door. It cannot certify that an address seen by an unrelated website is no longer available through another device, supplier or reseller.

The Provider Can Disappear While the Addresses Remain

The July 2026 action against NetNut makes this distinction measurable. Google, the FBI and industry partners disrupted accounts, applications and domains associated with the network. Google said the action caused significant degradation and reduced the available device pool by millions.

Layer3 Intel then measured what happened to the observed exit inventory. Its NetNut takedown analysis reported a 99.92% fall in unique NetNut exit IPs observed per hour by 5 July. At the branded network layer, the service had collapsed.

The address layer told a less tidy story. Of the IPv4 addresses observed through NetNut in its final one to two days, 78.81% appeared through other proxy networks during the following 14 days.

That result does not prove that the same televisions, routers or other devices moved between providers. Public IP addresses change, multiple devices can share an address through carrier-grade NAT, and several suppliers or resellers may expose overlapping inventory. Layer3 Intel also estimated, after applying its selected June baseline, that about 1.06 million fewer addresses reappeared than ordinary churn predicted. The takedown had a measurable effect.

The bounded conclusion is still useful: a provider name can almost disappear while much of its recently observed public-address inventory remains visible elsewhere. Our analysis of the measurement sets out what that overlap can and cannot establish.

Provider identity is not a stable security boundary. App-store presence is not one either.

The Destination Sees the Last Step

The website receiving the traffic cannot inspect the television, recover the consent screen or ask which app store approved the software. It sees the end of a longer chain:

device -> public IP -> supplier -> proxy pool -> reseller -> buyer -> destination

Most of that history is hidden at request time. The destination can observe the connection, the client and the work being attempted.

A request from an Australian residential ISP may belong to a customer at home. It may also be a request sent from another country and relayed through that connection. The address locates the exit. It does not authenticate the operator.

Peakhour therefore treats residential proxy detection as evidence inside the request decision. It sits beside credentials, account state, network and client fingerprints, route sensitivity, behaviour and recent outcomes.

The same proxy observation can support different actions:

Opening a public, cached page may require no intervention beyond recording the signal.
Trying one password across many accounts may justify a shared rate limit or block.
Changing a recovery email from a first-seen client may require stronger verification.
Repeating expensive API work across rotating addresses may call for a limit keyed on the credential, client and route rather than the IP alone.

The proxy result changes how much evidence the service requires. It does not select the action by itself.

A Compliant Path Still Has Value

The limits of consent do not make consent unimportant. The limits of app-store enforcement do not make enforcement pointless.

If a platform permits bandwidth-sharing software, it should demand more than a provider's assurance that users opted in. A credible path needs authoritative and recurring consent, a persistent participation indicator, effective withdrawal, buyer and use-case controls, private-network protections, supplier and reseller lineage, incident handling and independently testable records.

Those controls can distinguish accountable supply from hidden or compromised enrolment. They can protect households and make abuse harder. They cannot guarantee that no residential connection will carry a proxy request, and they cannot tell a destination what to do with the request already in flight.

The mistake is expecting one control to answer a question it cannot observe.

Consent answers whether a device was knowingly enrolled. An app-store decision answers whether a distribution channel permits the software. The destination still has to decide whether the request may log in, reset an account, buy limited inventory, scrape an API or consume expensive origin work.

That decision belongs on the request path, using current evidence. A residential address tells us where the request left the network. It does not tell us who initiated it or what they intend to do.

For the operating model, read A Proxy Flag Is Not a Security Policy and A Proxy Takedown Is Not a Security Control.

A Proxy Takedown Is Not a Security Control

2026-08-03T09:00:00+10:00

A residential proxy network is disrupted on Tuesday. On Wednesday, a password-spraying campaign is still reaching your login route through consumer IP addresses. The takedown changed upstream supply. It did not stop the campaign at your edge.

Legal action, platform enforcement, domain seizures, malware removal, and industry coordination matter. They can protect device owners, remove capacity, raise operating costs, and expose relationships that were previously difficult to see. They do not inspect the request currently approaching your application or decide whether it should be allowed to change an account.

That is the boundary security and fraud teams need to keep clear. A takedown is an ecosystem intervention. A provider label is time-bound intelligence. A request decision is a control in the path of the work being attempted.

The first article in this series compares what the IPIDEA and NetNut actions changed. The second examines why a network can disappear while its former IP inventory remains visible elsewhere. This final article starts after enforcement: when the network has changed, the headlines have moved on, and the application still needs to handle live traffic.

Disruption Changes the Network, Not the Destination's Job

Google's January 2026 IPIDEA disruption combined legal action against control and marketing domains, intelligence sharing, and Google Play Protect enforcement. Google said the action significantly degraded the network and reduced its available device pool by millions. It also warned that reseller agreements created overlap between exit pools and made definitive attribution difficult.

In July, Google took coordinated action against NetNut. Google said it disabled accounts and services used for command and control, shared intelligence, and used Play Protect against applications incorporating known NetNut SDKs. It estimated the network at a minimum of two million devices and reported 316 distinct threat clusters using suspected NetNut exits during one week in June.

Those are Google's findings and estimates, not a claim that every address associated with either provider was malicious. They still show why enforcement deserves support. Reducing compromised supply helps the people whose connections were being used and makes abuse infrastructure more expensive.

The destination's exposure is different. Google also said that operators affected by the earlier IPIDEA disruption began buying capacity from competitors and acting as resellers. A storefront can lose part of its own pool while continuing to sell access sourced elsewhere. Buyers can move as well. Demand, tooling, accounts, target lists, and attack behaviour do not disappear with a control domain.

If your production rule is provider = IPIDEA, the disruption may make that rule less accurate precisely when the incident looks most successful.

Expect Migration Before You Expect Silence

Post-disruption network-layer observations reinforce that warning, but they need careful attribution. Lumen's Black Lotus Labs reported from its own backbone telemetry that IPIDEA lost traffic and victim population after the January action, then rebuilt infrastructure and recovered. The same Black Lotus Labs proxy-ecosystem report describes backend connections and resale relationships across several networks.

That report reflects Lumen's visibility, detection methods, and assessments. It is not a complete census of the internet, and an infrastructure relationship does not prove that every request, exit, or customer belongs to one named operator. Its operational lesson is narrower and useful: supplier and reseller relationships can change faster than a static provider label.

After a disruption, assume four kinds of movement until evidence shows otherwise:

existing exits reconnect through replacement infrastructure;
a provider buys or resells another pool;
customers shift to a different storefront or whitelabel service;
the same operator rotates through new IPs while keeping its browser, credentials, request sequence, and target set.

The defender's task is not to guess the next brand name. It is to keep the intelligence current and preserve enough behavioural continuity to recognise the work after the address changes.

Rebaseline the Intelligence

A disruption date should trigger a data review, not an automatic claim of coverage.

Take a pre-action baseline by route: request volume, proxy prevalence, provider attribution, challenge completion, authentication outcomes, blocks, 429 responses, transaction completion, origin work, analyst review, and support contacts. Then compare the same measures immediately after the action and as the market adapts.

Refresh feeds and internal observations on their own collection cadence. Do not merge a historical provider association into a permanent property of the IP. For each proxy or network result, retain:

observed_at
indicator or network value
provider attribution, if any
attribution source and dataset version
confidence and reason
first_seen and last_seen where available

observed_at matters because a residential address can leave a pool, return to a different subscriber, or appear under another reseller. Confidence matters because “seen as an exit” and “attributed to this provider” are different claims. Provider attribution should be allowed to decay, be superseded, or remain unknown.

This is the provenance contract described in What a Residential Proxy Decision Log Should Contain. Keep the current request, the time-bound observation, the policy revision, the selected action, and the outcome connected. A retrospective feed correction should not silently rewrite what the control knew at decision time.

Correlate the Actor's Work Across IP Rotation

IP rotation is meant to break IP-only memory. Build continuity from the parts of the operation that are harder or more expensive to change together.

Useful correlation keys include:

account, tenant, API credential, session, or target object;
credential reuse and failure outcomes across many accounts;
versioned TLS, HTTP, browser, or device fingerprint cohorts;
route order, timing, retry behaviour, and automation cadence;
checkout, promotion, recovery, or payment-instrument patterns;
request cost and repeated origin or database work.

None of those fields proves identity by itself. A common browser fingerprint can group many legitimate users, and an account can be shared. The value comes from agreement across independent observations and from the route being protected.

Residential Proxy Detection for APIs Without JavaScript applies the same principle to machine traffic: use network and protocol evidence in the request path, then combine it with the API identities and outcomes already available. Do not make browser JavaScript a prerequisite for detecting rotation against an API.

Keep the Action Route-Specific

The takedown does not tell you what to do with a request. Neither does the proxy flag. As A Proxy Flag Is Not a Security Policy explains, the signal should change how much corroboration or friction a request needs, not select one global response.

Use the action that fits the route and the cost of error:

Allow low-risk activity when the session and behaviour are consistent.
Log new or uncertain intelligence while measuring the local population.
Challenge an interactive client when it can provide more evidence and has a safe recovery path.
Rate limit repeated or expensive behaviour across the account, client cohort, route, token, and outcome keys that survive IP rotation.
Step up authentication or transaction verification when the request can transfer account control or value.
Block when evidence is strong, harm is current, and a narrower action cannot protect the route.

Account creation, login, password reset, checkout, and public APIs have different identities and failure modes. Five Routes, Five Residential Proxy Decisions provides a concrete policy split. The important post-disruption change is to tune each contract with current observations rather than adding a site-wide deny rule for yesterday's provider.

Measure Protection and Customer Cost Together

An enforcement event can make a threat-intelligence chart fall without improving an application's outcome. A provider-labelled cohort may shrink because attribution changed. Attackers may reduce request rate, move to a new pool, or switch routes. Legitimate customers may still be caught behind shared networks.

Measure the control where the business feels it:

successful login, recovery, checkout, signup, and API completion;
confirmed abuse, account loss, fraud, scraping, and costly operations;
challenge presentation, completion, failure, and abandonment;
blocks and limits overturned by analysts;
origin work and application cost avoided;
support contacts, time to resolution, and exception volume;
policy changes, rollbacks, and rules past their review date.

Support cost is part of control cost. If a policy creates a queue of customers who cannot recover accounts, the team needs to see that beside the reduction in suspicious requests. Peakhour Residential Proxy Detection keeps the proxy signal in the live web and API decision. Bot Management and Advanced Rate Limiting add behavioural and route-aware controls, while API Security protects machine-facing operations without assuming an interactive browser.

The objective is a measurable change in harmful outcomes without an unacceptable change in legitimate completion.

Questions to Ask a Security or Fraud Vendor

Post-disruption due diligence should test operational evidence, not invite another pool-size claim.

Ask:

Do you retain observed_at, source, dataset or detector version, confidence, and provider-attribution reason separately?
How quickly can a provider label decay or change after infrastructure, reseller, or ownership movement?
Can you show what changed in your coverage after the IPIDEA and NetNut actions, including misses and attribution uncertainty?
Can your controls correlate behaviour across rotating IPs without treating a fingerprint as a person?
Can we set different allow, log, challenge, rate-limit, step-up, and block policies by route and API operation?
Does API detection work in the request path without a JavaScript lookup or a second application call?
Will the decision record show the inputs, policy revision, reason codes, action, and later outcome?
Can we compare security outcomes with customer completion, support cases, analyst overturns, and origin cost?
Who owns an emergency rule, when does it expire, and how quickly can we roll it back?

A credible answer should expose limits. If the vendor cannot distinguish an enforcement event, a provider association, and a request decision, it will be difficult for your team to do so during an incident.

Keep the Boundary Honest

Takedowns are necessary work. They protect consumers and disrupt infrastructure at a scale an individual destination cannot reach. They should continue.

Your application still has to judge the request in front of it.

Refresh the intelligence. Keep its time, source, attribution, and confidence. Follow behaviour across address changes. Apply a route-specific action. Record what happened next, including the customer's cost.

Enforcement can reduce the supply of abusive infrastructure. Only a control on the destination's current request path can protect the account, transaction, or API operation being attempted now.

When a Proxy Network Dies but Its IPs Survive

2026-08-03T08:30:00+10:00

A residential proxy network goes dark. Its domains are seized, its control systems are disrupted and its branded pool almost disappears. Two weeks later, many of the same public IP addresses appear through other proxy services.

Did the takedown fail? Did the same devices move? Were several providers selling the same supply all along?

The honest answer is narrower: the address inventory overlapped across time. That is valuable evidence, but it is not device identity, ownership or motive.

This distinction matters to security and fraud teams deciding what to do with traffic. It also matters to buyers, auditors and researchers trying to establish whether a proxy provider controls the supply chain it describes.

One Address Sits Above Several Relationships

The destination website sees the last layer in a longer chain:

device -> public IP -> SDK or supplier -> proxy pool -> reseller -> buyer -> destination

Each arrow represents a separate relationship.

The device may be a phone, laptop, streaming box, household gateway or server. Software on it, or elsewhere on the same network, sends a buyer's traffic out through a public IP assigned by an ISP or mobile carrier.

An SDK or supplier enrols that capacity. A proxy pool makes it selectable. A reseller may buy the service upstream and sell it under another name. A buyer chooses a location or session through an API. The destination sees a request from the exit address, not this commercial history.

Those layers do not map one-to-one. Several devices can share one public address through a household router or carrier-grade NAT. One device can receive different addresses over time. One supplier can feed several pools. A pool can combine direct supply with upstream inventory. A reseller may not know which device, supplier or SDK produced a particular session.

Our article on how bandwidth sharing feeds residential proxy networks covers the ways capacity enters this chain. The question here is different: what can we infer when a named network disappears but addresses associated with it remain visible elsewhere?

What the NetNut Measurement Found

On 2 July 2026, Google, the FBI, Lumen and other partners took action against the NetNut residential proxy network, also known as Popa. Our comparison of the IPIDEA and NetNut actions separates the controls and public claims involved. Google said it disabled accounts and services used for command and control, shared technical intelligence, and updated Play Protect to disable applications known to contain NetNut SDKs. Google estimated that the network included at least two million devices and said it had high confidence that multiple proxy brands white-labelled NetNut capacity.

Layer3 Intel then published a useful post-event measurement. Its NetNut takedown analysis says the number of unique NetNut exit IPs it observed per hour fell by 99.92% by 5 July. At the brand or gateway layer, that is a decisive decline.

The cross-network result was less absolute. Layer3 Intel took IPv4 addresses it had observed through NetNut in the 30 days before the shutdown and checked whether they appeared through other networks during the following 14 days. Among addresses seen through NetNut in the final one to two days, 78.81% reappeared elsewhere.

The researchers also tried to account for ordinary churn. They applied reappearance rates from a 4 June placebo cutoff to the July cohort. On that basis, they expected about 17.96 million recent addresses to reappear and observed 16.90 million. The difference produced a baseline-adjusted estimate of about 1.06 million IP addresses removed from the wider proxy ecosystem beyond normal churn.

These measurements support three bounded findings:

NetNut's branded, observable exit service collapsed.
Much of the recent public-address inventory associated with NetNut was observable through other proxy networks after the disruption.
Reappearance was lower than the selected June baseline, consistent with a real takedown effect beyond ordinary address churn.

That is already operationally important. A provider name can disappear while some of the address inventory remains commercially reachable.

An IP Match Is Not a Device Match

The same measurement does not prove that the same physical device survived, moved between suppliers or carried two SDKs.

Public addresses are assigned to connections, not permanently engraved on devices. DHCP leases expire. Mobile subscribers move between network gateways. Consumer routers reconnect. Carrier-grade NAT lets many subscribers share public addresses from a provider-controlled pool. RFC 6598 documents shared address space used by service providers for CGNAT, but the ambiguity exists outside that range too: the destination only sees the translated public address.

If 203.0.113.x appears through Network A before a cutoff and Network B afterwards, several explanations fit:

the same device was available through both networks;
different devices behind the same household or carrier address were enrolled;
an ISP reassigned the address to a different subscriber;
a shared upstream supplied both pools;
one provider resold another provider's capacity;
the enumeration system attributed one of the observations incorrectly.

IP overlap increases confidence that address inventory is shared or recycled across the market. It does not identify which explanation is correct for any one address.

It also does not prove supplier ownership. A provider may own infrastructure, contract directly with a supplier, buy capacity through an intermediary, or combine all three. Nor does overlap prove that a device owner did not consent. Consent belongs to a specific person, device, software version, disclosure and time. An IP address contains none of those records.

Most importantly, overlap does not prove motive. It can show that a buyer's request travelled through an observed exit. It cannot establish what the supplier, reseller or provider knew, why a buyer selected the route, or whether the destination request was benign or abusive.

Google's earlier IPIDEA investigation reached beyond address overlap. It analysed applications, Windows binaries, SDK code, command infrastructure and shared server pools, and paired that technical work with platform and legal action. Even then, Google noted that overlaps between exit nodes made definitive quantification and attribution difficult. That is the right standard: use IP observations as one part of a multi-layer attribution, not as a shortcut through the layers.

Read the 1.06 Million Estimate as an Estimate

Layer3 Intel's analysis is stronger than a simple before-and-after count because it recognises ordinary churn and uses an age-matched comparison. Its scale and high-frequency observation also give it a useful view of the market.

The public methodology still leaves material uncertainty:

Enumeration is proprietary. The post describes the volume and timing of observations, but does not publish the complete sampling system, provider coverage, request selection, deduplication rules or validation set. Readers cannot independently reproduce the population from the article alone.
An IP is a noisy unit. Dynamic addressing and CGNAT break a stable link between address, subscriber and device. Counting distinct IPv4 addresses can overstate devices and obscure shared use.
The windows choose what can reappear. The source cohort covers 30 days; the follow-up covers 14. Shorter or longer windows would change both the raw overlap and the churn model.
There is one published placebo cutoff. A single June comparison is useful, but it does not show the normal week-to-week distribution, seasonal effects or whether that period was representative.
No confidence intervals are published. The 1.06 million figure is presented as a point estimate. The post does not provide uncertainty bounds, sensitivity analysis or an error rate for network attribution.
The counterfactual is observational. The difference from baseline is consistent with the takedown removing capacity. Other simultaneous supplier, demand, enforcement or measurement changes could contribute.

None of these limits makes the result useless. They set its resolution. “About 1.06 million fewer addresses reappeared than this baseline predicted” is supported by the published method. “Exactly 1.06 million devices were removed” is not.

What a Sourcing Claim Can Responsibly Prove

A vendor can responsibly prove facts about processes and records it controls.

It can show which entity contracted each direct supplier, which software package enrolled a device, what disclosure was presented, how affirmative consent was recorded, how withdrawal works, which versions were active, and whether a buyer's session can be traced to that evidence. It can document reseller dependencies, prohibit undisclosed sub-supply, test compliance and publish exceptions.

A policy page can prove that a policy exists. A contract can prove that parties accepted terms. Neither proves that every active exit followed the policy.

“Ethically sourced” is therefore too broad unless the provider defines the claim and its coverage. Does it apply only to a proprietary pool? To upstream suppliers? To every session sold by resellers? Does consent come from the device user, the account holder, the network owner or all relevant parties? How quickly is an exit removed after withdrawal?

The strongest claim is session-level and time-bound: for this delivered connection, the provider can trace the supply path to a named enrolment mechanism and current evidence, subject to stated audit limitations. Anything less should be described at its actual scope.

What Auditors and Buyers Should Request

Do not ask only whether sourcing is ethical. Ask for evidence that follows the chain:

a current inventory of direct suppliers, upstream pools and white-label dependencies;
the percentage of delivered traffic covered by direct, auditable sourcing rather than policy language alone;
SDK names, package hashes, versions, distribution channels and signed build provenance;
the exact user disclosure and consent event, including timestamp, software version and withdrawal path;
proof that the person giving consent had authority over the device and network connection;
controls for CGNAT, reassigned addresses, duplicate exits and concurrent appearance across providers;
session-level lineage from buyer request to pool, supplier and enrolment record, sampled by an independent auditor;
contractual limits on sub-suppliers, plus evidence that those limits are tested;
complaint, removal and incident records, including time to disable an exit across every downstream reseller;
methodology for advertised pool size, unique-IP counts and active-device counts, with uncertainty and deduplication rules;
independent test results, exceptions and remediation, not only a clean summary statement.

Buyers should also keep their own record: product and upstream named at purchase time, contract revision, stated sourcing basis, session identifiers where available, destination and purpose, and the control used to prevent abuse. A provider's assurance does not transfer accountability for how the buyer uses the route.

Defenders Still Have a Request to Judge

Post-takedown research can improve proxy intelligence. It cannot turn an IP address into a verdict.

An address that reappears across pools may deserve closer observation, especially on login, account recovery, checkout or expensive APIs. The action should still depend on route, account state, client consistency, behaviour and recent outcomes. That is why a proxy flag is not a security policy.

Keep the provenance of the observation as well. Record which network label was seen, when it was observed, which dataset and version supplied it, what other evidence changed the action, and what happened next. Our guide to residential proxy decision logging sets out that operating record.

A takedown can kill a service without retiring every address that passed through it. The surviving IPs tell us that the market has shared, changing inventory. To say who supplied it, whether a device owner consented, or why a request was sent, we have to follow the rest of the chain.

For the destination, the work continues with the request. The final article in this series explains why a proxy takedown is not a security control and what security and fraud teams should rebaseline after a disruption.

IPIDEA and NetNut: What Two Residential Proxy Takedowns Actually Changed

2026-08-03T08:00:00+10:00

Two large residential proxy networks were disrupted within six months. In late January, Google announced action against IPIDEA. In July, Google, the FBI, Lumen and other partners acted against NetNut, also known as Popa.

Both operations interfered with infrastructure that connected home devices to paying proxy customers. Both prompted Android protections and intelligence sharing. Both were expected to affect providers beyond the name on the announcement.

They were not identical operations, and neither removed residential proxy risk from a login page, checkout, advertising campaign or API.

For security and fraud teams, the useful question is narrower than whether a network was “taken down”. Which parts stopped working, which sources of supply became harder to use, and what still reaches the application?

The Actions Hit Different Parts of the System

The IPIDEA action announced in January combined several controls.

Google said it used legal action to take down domains used to control devices and proxy traffic, as well as domains used to market proxy products and software development kits. Google Play Protect was configured to warn users, remove known applications containing IPIDEA SDKs and block future installation attempts on certified Android devices. Google also shared technical intelligence with platform providers, law enforcement and researchers. Cloudflare disrupted domain resolution.

The July action against NetNut had a different public description. Google disabled Google accounts and associated services that it said NetNut used for command and control. It shared intelligence about SDKs and backend infrastructure, while Play Protect warned users and disabled known applications containing NetNut SDKs. Separately, Alarum Technologies, NetNut's parent company, confirmed in an SEC filing that the FBI had seized domains associated with NetNut and that additional domains were later seized.

That distinction matters. A domain seizure, a disabled cloud account and removal of an application are not interchangeable:

C2 and domain disruption can stop enrolled devices finding instructions or carrying proxy traffic through known control paths.
Account and service suspension removes infrastructure hosted on a provider's platform.
Play Protect enforcement reduces active Android supply and makes the same known applications harder to reinstall.
Intelligence sharing lets other platforms and network operators identify related software and infrastructure.

Each action raises operating cost. None proves that every endpoint, reseller account or replacement control path has disappeared.

IPIDEA Exposed a Shared Supply Chain

Google's IPIDEA investigation described more than 600 Android applications across multiple download sources, 3,075 Windows file hashes that contacted its first-tier domains, and a changing pool of roughly 7,400 second-tier servers. Google also connected several proxy, VPN and SDK brands to common operators and infrastructure.

The company said the disruption reduced the available device pool by millions. It also observed more than 550 tracked threat groups using addresses identified as IPIDEA exits during one seven-day period in January 2026. The reported activity included password spraying and access to victim SaaS and on-premises environments.

The overlap is more useful to buyers than the largest headline number. Different product names and SDK labels fed common infrastructure, while reseller and partnership arrangements created overlap between exit pools. A buyer choosing a second brand could still be purchasing access to the same upstream capacity.

That structure is covered in more detail in How Bandwidth Sharing Feeds Residential Proxy Networks. The point for this comparison is that IPIDEA's disruption reached beyond one storefront because control, distribution and supply were shared.

NetNut Showed the Commercial Effect More Clearly

Google estimated that the NetNut network contained at least two million devices. During one week in June, it observed 316 distinct threat clusters using suspected NetNut exits, including cybercrime and espionage groups. Google also said NetNut ran a substantial white-label reseller programme and assessed with high confidence that a number of popular proxy brands were reselling the network.

Those figures should not be placed in a league table against IPIDEA's. “Devices removed” is not the same measure as an estimated network size. “Tracked threat groups” and “distinct threat clusters” may not use the same counting method. The observations came from different weeks and networks. They establish material scale and misuse, not a defensible ranking.

The stronger comparison is operational. Google later reported that some networks affected by the IPIDEA action appeared resilient: operators whose own supply degraded bought capacity from competitors and became resellers. Its NetNut action was designed with that adaptation in mind.

Alarum's disclosures show that the July action did affect the business. On 3 July, the company said the seized domains were disrupting part of its services and could have a material adverse effect if the disruption continued. It subsequently announced a temporary pause of traffic through relevant network services. In its 13 July update, Alarum said the events had materially affected its business and operations, that an external forensic review was continuing, and that an efficiency plan was expected to affect roughly one-third of its workforce. It was still evaluating how to restore service.

That is evidence of business and service disruption. It is not evidence that every NetNut-related device was cleaned, every reseller lost access, or all residential capacity sold under other names stopped.

Accountability Requires Keeping the Claims Separate

This market has competing accounts of the same infrastructure.

In its March 2026 annual report, Alarum described its network as serving business uses including public web-data collection, price comparison, advertising verification and cybersecurity. It said its experience allowed customers to collect data ethically and effectively. These are the provider's descriptions of its products and intended uses.

Google reported different findings from its threat intelligence and technical investigation. It linked NetNut SDK components to home devices and larger botnets, reported suspected exits used by cybercrime and espionage clusters, and said many brands white-labelled NetNut capacity. For IPIDEA, it reported applications with unclear disclosure, common infrastructure behind several brands, and extensive use by tracked threat groups.

Alarum's official response did not address or endorse Google's technical characterisation, and it did not publish a competing completed investigation. It acknowledged the domain seizures and disruption, said it was investigating whether third parties had misused its services or network, promised cooperation with law enforcement and later said its external review had reached no final conclusions.

The evidence therefore supports several restrained conclusions:

Google identified infrastructure and software it attributed to the two proxy networks and observed serious misuse of their exits.
Google reported significant degradation and reduced device availability; Alarum's disclosures independently confirm disruption to NetNut's operations.
Reseller and white-label relationships make a retail provider name weak evidence of independent supply.
Public reporting does not establish that every customer used the services unlawfully, that every enrolled device joined without consent, or that corporate management directed every observed act.

For procurement and accountability teams, that last boundary is not a reason to ignore the findings. It is a reason to ask better questions. A provider should be able to identify its upstream networks, explain how each endpoint was enrolled, show how consent can be withdrawn, disclose white-label dependencies, describe customer controls, and produce evidence when those claims are challenged.

“Ethically sourced” is not useful due diligence unless the buyer can test what it means.

The Destination Risk Continued

A takedown acts upstream. The protected application sits downstream.

When an SDK is removed or a control domain is seized, some devices leave a pool and some routes fail. That reduces available supply and may interrupt active campaigns. It does not reverse requests already made, clean every non-Android device, reveal every replacement domain, or prevent an operator buying another provider's exits.

The destination still receives requests from consumer and small-business IP addresses. Some belong to customers. Some are shared through carrier-grade NAT. Some are privacy services. Some are residential proxy exits that have not yet appeared in a feed. The application cannot infer who controls a request from the address alone.

This is especially important when the household owner may also be a victim. When Home Devices Become Attack Infrastructure explains why application teams should preserve evidence without attributing the request to the subscriber.

What Buyers Can Now Demand

The two operations give procurement, security and fraud buyers better questions to put to a proxy supplier.

Ask the vendor to identify the retail provider, upstream source, reseller relationship, endpoint-enrolment method and removal process. Contract for notification when an upstream source changes. A new brand or ASN is not proof of a new supply chain.

Ask which proportion of delivered sessions can be traced to direct, auditable sourcing. Require the assurance to cover upstream and white-label capacity, not only a proprietary pool. Check whether withdrawal removes an exit from every downstream reseller and how the provider proves that happened.

Ask what the provider knew and when. A policy page states an intention. Session-level supplier, software, consent and removal records provide evidence that can be tested.

The takedowns removed real infrastructure and imposed real costs. They also demonstrated why disruption is a continuing process rather than a permanent state. Shared supply can move and resellers can change upstream providers.

The operational response belongs in the final article in this series, A Proxy Takedown Is Not a Security Control. It covers the live detection, route policy and outcome measures a destination service should rebaseline after enforcement.

The next article in this series, When a Proxy Network Dies but Its IPs Survive, examines what post-takedown address overlap can prove and where the inference stops.

When Home Devices Become Attack Infrastructure

2026-08-01T12:30:00+10:00

A compromised streaming box under a customer's television is not an endpoint your application team can patch.

It can still send traffic to your login page.

Residential proxy and botnet supply increasingly includes ordinary connected devices: streaming boxes, routers, phones, PCs, projectors, and other hardware that stays online behind a consumer connection. Some owners knowingly share bandwidth. Some accept a vague disclosure inside an app. Others never consent because the device or software was compromised.

The sourcing problem matters to platforms, app stores, vendors, ISPs, and law enforcement. The destination service has a more immediate job. It must decide what the request is allowed to do.

The Exit Looks Like a Customer Network

When third-party traffic leaves through a household device, the destination sees the household's public IP. The address may belong to a well-known Australian ISP. It may have no negative reputation. It may also be shared with legitimate activity from the same home or carrier network.

This is why an IP allow-list, deny-list, or country rule cannot establish who controls the request. The source is real. The relationship between that source and the operator is hidden.

Our earlier article, How Bandwidth Sharing Feeds Residential Proxy Networks, explains the supply chain. The defensive consequence is that trust has to move up from the address to the request, session, route, and behaviour.

Quiet Monetisation Changes the Compromise

In 2025, Palo Alto Networks Unit 42 documented attackers exploiting vulnerable GeoServer instances and deploying a legitimate passive-income application and SDK. The code matched the vendor's official version; the installation and use were unauthorised. Unit 42's proxyware campaign report explains why legitimate binaries can still be part of a compromise.

That payload can be quieter than ransomware or cryptomining. It produces recurring value without making the device's failure obvious. For a destination application, quieter supply means a proxy exit can remain useful for longer.

The FBI's 2025 BADBOX 2.0 alert described Android-based streaming devices, projectors, tablets, digital picture frames, and aftermarket vehicle systems affected before purchase or during setup. The FBI said compromised devices could become part of residential proxy services and botnets used for criminal activity.

These reports do not mean every inexpensive smart device is compromised. They show why household provenance is not a security verdict.

What the Application Can Observe

The destination cannot inspect the television or router. It can observe the work attempted through it:

route and operation;
authentication and account state;
residential proxy and broader IP context;
TLS, HTTP, and browser fingerprint cohorts;
device and session history where available;
request timing and sequence;
credential exposure;
failures, retries, and response-code loops;
application and origin cost.

Several devices may also share the public address. A permanent household ban can punish the subscriber whose device was compromised. Correlate the behaviour using keys that fit the route.

Control the Sensitive Journey

The action should follow what the request can change or consume.

For public cached content, proxy use may need no intervention. For login, count failures across account and client cohorts rather than relying on the exit. For password reset, keep responses consistent and limit repeated recovery attempts. For checkout or account changes, carry the earlier session risk forward and request stronger verification when the consequence rises. For expensive APIs, use identity- and cost-aware budgets.

Peakhour Residential Proxy Detection contributes a live network signal for browser and API traffic. Bot Management combines it with the route, client and behaviour already visible in the request path. The objective is not to identify the appliance. It is to stop relayed traffic from inheriting unconditional trust from the household address.

Platform Enforcement Reduces Supply, Not Every Request

Since August 2019, Google Play has required an app facilitating proxy services to third parties to make proxying its primary, user-facing core purpose. The current Device and Network Abuse policy retains that rule. It gives Google a basis for removing unrelated apps that hide proxy functionality, regardless of whether an SDK vendor describes enrolment as consensual.

That policy can reduce deceptive supply. Device takedowns and legal action can disrupt infrastructure. Google's IPIDEA operation combined legal action, platform enforcement, and industry coordination.

Application controls are still required. Existing exits do not disappear at once, private pools remain, and new supply can emerge before datasets identify it.

The 2026 actions against IPIDEA and NetNut show both sides of that boundary. Our takedown comparison covers the upstream disruption; the follow-up on surviving proxy IP inventory explains why an address seen after a takedown does not, by itself, identify the device or supplier behind it.

Preserve Evidence Without Blaming the Customer

When an event is challenged or blocked, record the route, proxy and network evidence, client cohort, account or token context, policy revision, selected action, and outcome. Avoid language that says the household owner attacked the service. The evidence usually supports a narrower statement: traffic reached the application through this connection and matched this behaviour.

That distinction matters for support, fraud review, and incident response. The subscriber may be a victim too.

Application teams cannot repair every compromised box on the internet. They can refuse to let a residential address stand in for identity, intent, or permission.

Residential Proxies Turn Layer 7 DDoS Into a Route Problem

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

Not every Layer 7 DDoS attack looks large at the edge.

A residential proxy pool can spread requests across thousands of consumer addresses. Each exit sends a modest amount of traffic. Per-IP limits stay quiet. Aggregate bandwidth may look manageable. The application still falls over because the requests concentrate on work that is expensive to perform.

Search, login, checkout, GraphQL, report generation, uncached rendering, and API aggregation can fail long before the network link is full. Residential distribution turns the incident into a route and resource problem.

Count the Work, Not Just the Requests

Two HTTP requests can have radically different cost.

A cached image may be served at the edge with no origin work. A search request may query several indexes. A login can invoke password hashing, credential checks, session state, and downstream identity services. A GraphQL operation can expand into many resolvers. An export can hold database and worker capacity for seconds or minutes.

Cloudflare's explanation of application-layer DDoS attacks describes the core distinction: Layer 7 attacks target the application work involved in processing apparently legitimate requests.

Map the routes before an incident:

which requests are cacheable;
which invoke database, search, identity, payment, or third-party dependencies;
which hold workers, connections, queues, or memory;
which can be assigned a cost class;
which business journeys must remain available under pressure.

Requests per second is still useful. It is not the complete capacity model.

IP Limits See the Distribution, Not the Campaign

A per-IP limit catches simple floods and protects against one noisy client. Keep it as one layer.

Residential proxies are designed to distribute source addresses. A campaign can remain below an IP threshold while one fingerprint cohort, route sequence, query shape, account pattern, or operation class grows rapidly across the fleet.

Useful aggregate keys include:

route + fingerprint cohort
operation + query cost class
login route + account + failed outcome
tenant + API credential + expensive operation
route + proxy state + response outcome

No key is universally safe. A common browser or mobile SDK can create a large legitimate cohort. Observe bucket sizes and successful outcomes before using a grouping key for enforcement.

Proxy Detection Changes Confidence

A residential proxy result does not prove DDoS. It changes how the request is interpreted when other evidence agrees.

For example:

a new residential exit fetching one cached page adds little risk;
many exits sharing a narrow client cohort and repeatedly missing cache on an expensive route add more;
the same pattern causing queue growth, timeouts, and origin errors supports immediate mitigation.

Google's IPIDEA investigation showed how large and commercially interconnected a residential exit pool can become. Application defenders should assume source diversity is purchasable.

Peakhour DDoS Protection combines anomaly detection, route-aware rate limits, bot and WAAP context, cache policy, and origin protection in one request path. RESIP contributes a signal; the action comes from the route, behaviour, and current service pressure.

Preserve a Clean Path

Emergency mitigation often fails by protecting the server from everyone.

Decide in advance which journeys need to survive:

existing authenticated sessions;
account recovery;
checkout or payment confirmation;
status and support information;
partner or operational APIs;
cacheable public content.

Controls can then narrow around the attacked resource. Serve cacheable responses at the edge. Reduce budgets for costly anonymous operations. Apply stricter limits to repeated failures. Challenge interactive browsers where there is a recovery path. Preserve authenticated or known-good traffic when the evidence supports it.

Challenges do not solve every flood. Browser automation can complete them, and challenge generation can itself consume capacity. Machine-to-machine APIs need protocol-appropriate responses. RFC 6585 defines HTTP 429 Too Many Requests and the optional Retry-After header, but clients and operators still need to prevent retries from amplifying pressure.

Watch the Origin Outcome

Mitigation evidence should connect the request to what happened behind it:

cache hit or miss;
origin request avoided;
application latency and response status;
queue, worker, connection, and dependency pressure;
rate-limit, challenge, or block action;
successful user journey completion;
policy revision and activation time.

A rising block count only describes the control. Protection is visible when essential routes remain available, origin pressure falls, and legitimate completion stays within an acceptable range.

Rehearse the Policy Before the Flood

During an incident, teams reach for the keys they already have. If every counter is bound to source IP, residential distribution will force a broad emergency rule.

Choose one expensive route now. Measure normal cost and cohort sizes. Add observation counters for route, identity, fingerprint, proxy state, and outcome. Define the threshold that indicates resource pressure, the first reversible action, the owner, and the rollback condition.

For the first rehearsal, one expensive route is enough. If the team can describe its normal cost, see distributed pressure, apply a bounded action, and preserve legitimate completion, it has a mitigation pattern worth extending. An address ban on its own does not provide that pattern.

Five Routes, Five Residential Proxy Decisions

2026-08-01T12:10:00+10:00

Account creation and password reset may sit under the same /account/ prefix. They are not the same security decision. One creates a new identity; the other can transfer control of an existing one.

The same problem appears when a team applies one residential-proxy action across login, checkout, and public APIs. Low-risk traffic is rejected, shared networks create support cases, and the attacker moves to an unlabelled exit or another route.

Policy has to begin with what each request can do. These five routes have different identities, costs, recovery paths, and abuse patterns, so the proxy result changes each one differently.

1. Account Creation

Signup abuse creates fake accounts for promotion fraud, spam, inventory reservation, scraping, or later account farming. A residential proxy helps the operator distribute registrations and make geography look ordinary.

Useful evidence includes:

registrations across a shared device or fingerprint cohort;
repeated email, phone, payment, referral, or promotion patterns;
verification completion and time to complete;
route sequence before and after signup;
residential proxy and network context;
account creation velocity across IPs and client cohorts.

A first-seen proxy result may only justify logging. Proxy use combined with repeated device evidence and failed verification can justify a shared limit or stronger verification. Preserve legitimate households and mobile networks by avoiding one-account-per-IP assumptions.

2. Login

Login protection has to handle password mistakes, credential stuffing, password spraying, and targeted account takeover without turning the attack into an account lockout service.

The OWASP Credential Stuffing Prevention Cheat Sheet recommends layered controls including MFA, breached-password checks, connection and device fingerprinting, and defence in depth.

For a residential proxy login, look at:

exposed credential state;
failures against this account across all IPs;
accounts attempted by this client cohort;
familiar device and session history;
normal or abnormal route sequence;
success, failure, MFA, and challenge outcomes.

One failure from a new address is weak evidence. Distributed failures across many accounts with a shared cohort are stronger. Rate limit the behaviour, not merely the exit.

3. Password Reset

Password reset is both a recovery mechanism and a route to account control. It also leaks information if response behaviour reveals whether an account exists.

OWASP's Forgot Password Cheat Sheet recommends consistent messages and response timing, side-channel delivery, rate limiting, and protection against excessive reset requests.

Residential proxy use should raise attention when it appears with account enumeration, repeated reset initiation, token guessing, or a new client followed by recovery-factor changes.

The action may be a tighter account-and-cohort limit, delayed processing, step-up verification, or a user notification. A broad IP block can stop legitimate recovery for every person sharing the exit.

4. Checkout and Stored Value

Checkout risk is not limited to card testing. Automated clients can reserve scarce inventory, abuse promotions, drain loyalty balances, test stored payment instruments, or change shipping details after account takeover.

Connect the network signal to the transaction:

established account and device history;
payment, address, basket, and promotion changes;
velocity across accounts and instruments;
prior login or recovery risk in the same session;
repeated declines and response patterns;
inventory or application cost created by the request.

A proxy signal on a normal repeat purchase may add little. The same signal after a breached-credential login and recovery-email change should carry more weight. Step-up verification or a bounded transaction hold can be safer than a network-wide deny.

5. Public and Partner APIs

APIs often lack browser JavaScript and interactive challenge support. They may also expose expensive search, export, GraphQL, or object-access operations.

Use the identities the API already has: tenant, token, API key, client certificate, object, operation, and schema outcome. Add network and fingerprint cohorts where they help group rotation.

The OWASP API Security Top 10 calls out unrestricted resource consumption and unrestricted access to sensitive business flows. Residential proxy rotation can distribute both. Route-aware limits should account for operation cost rather than applying one requests-per-minute value to the whole API.

Machine clients cannot complete a browser challenge. A predictable 429, reduced operation budget, token step-up, or deny response may be the correct protocol action.

One Signal, Five Policies

Peakhour Residential Proxy Detection feeds proxy evidence into the request decision with IP, credentials, device, behaviour, and route context. Advanced Rate Limiting can count using route, ASN, country, IP, TLS fingerprint, response code, and other request attributes.

That allows each route to have its own contract:

Route	Primary concern	Useful action
Account creation	Scaled fake accounts	Verify and limit across client cohorts
Login	Credential reuse and spraying	Count failures across account and cohort
Password reset	Enumeration and account recovery abuse	Consistent responses, account limits, step-up
Checkout	Fraud and stored-value loss	Transaction-aware verification or hold
API	Resource and business-flow abuse	Identity- and cost-aware limits

Run new policies in monitor mode first. Record proxy prevalence, actions, successful completion, false positives, challenge outcomes, and origin cost. Move to enforcement by route, with an owner and rollback condition.

The implementation work is to give each route an explicit contract, then verify that its action protects the journey it was written for. A shared proxy result can feed all five contracts without forcing all five routes into the same response.

Privacy Relay, Corporate VPN, or Residential Proxy?

2026-08-01T12:00:00+10:00

An application sees a login from an address that does not match the user's apparent location. The connection belongs to a relay, VPN, or proxy network.

That is a reason to look closer. It is not a reason to call the user malicious.

Privacy relays, corporate VPNs, consumer VPNs, carrier-grade NAT, and residential proxies all weaken the old assumption that an IP address describes one person in one place. They do it for different reasons and with different operating models. A security policy that reduces them to anonymous=true will either miss abuse or punish legitimate users.

Privacy Services Deliberately Separate Identity from Destination

Apple says iCloud Private Relay uses separate internet relays so no single party can see both who a user is and which sites they visit. It also lets the user preserve a general location or use a broader country-and-time-zone location. Apple's Private Relay overview explains the scope and the role of the relay addresses.

That design changes what a website can infer from the source IP. It does not remove the session, account, route, browser, or request behaviour available to the application.

A corporate VPN creates a different pattern. Many employees may exit through a small set of company gateways. The source can be stable and organisation-owned, but the address still represents a population rather than one device. A consumer VPN may rotate gateways and mix unrelated subscribers. Carrier-grade NAT can make a normal mobile or broadband address shared even when no privacy product is involved; RFC 6598 documents shared address space reserved for carrier deployments.

Residential proxy services are different again. A remote operator deliberately routes through consumer or ISP connectivity so the destination sees the household exit. Mobile proxy services use the same broad model through carrier connectivity, but should remain separately labelled because their sharing and attribution conditions differ. Either form of supply may come from an informed participant, an embedded SDK, compromised software or another path.

The network categories matter. They still do not establish intent.

Define the Expected Population

Policy should reflect the application and route.

A workforce portal may know its corporate VPN ranges and require device or certificate evidence. A consumer service should expect mobile networks, privacy relays, travel, and shared households. A country-restricted service may need stronger location verification than an online catalogue. An API used by fixed partners can enforce network expectations that would be unreasonable on a public login page.

Ask:

Is this network type expected for this user population?
Is the route public, authenticated, sensitive, or expensive?
Does the account have established device and session history?
Is the apparent location material to the transaction?
Can the client provide another form of evidence?
What does a false rejection cost?

The answer determines whether the network signal should be ignored, logged, challenged, or combined with stronger controls.

Use Context to Separate Risk from Privacy

Peakhour IP Intelligence and Residential Proxy Detection place network context beside credentials, device history, fingerprints, behaviour, route, and recent events.

Consider two logins through privacy infrastructure.

The first uses an established session, familiar device history, a normal route sequence, and one successful authentication. The second attempts many accounts, carries an exposed credential, has no normal session history, and repeats the same failure pattern across rotating addresses.

Both hide or replace the direct source address. Only one presents a strong account-abuse pattern.

The policy should be able to express that difference. Blocking every relay or VPN is not contextual security. It is a network-category ban.

Geography Needs the Same Restraint

IP geolocation is an estimate of network presence, not proof of a person's physical location. VPN gateways, relays, mobile routing, satellite networks, corporate egress, and proxy exits can all separate the address from the user.

Use geography as evidence proportionate to the decision. A content preference may tolerate a coarse estimate. A regulated transaction may require account evidence, verified identity, payment context, or an explicit location control beyond an IP lookup.

Avoid impossible-travel rules that treat every IP change as physical movement. A session can switch between mobile, Wi-Fi, VPN, and relay paths without the person travelling at all. Look for continuity in the account, device, session, and behaviour before escalating.

Choose an Action That Can Be Recovered From

The action can then scale with the evidence:

Allow expected privacy or corporate access with consistent session evidence.
Log an unfamiliar network category on low-consequence routes.
Apply tighter rate limits when repeated behaviour spans accounts or rotating exits.
Challenge an interactive client when network change appears beside account risk.
Require step-up verification for recovery, payment, or access-control changes.
Block confirmed automated abuse with bounded route and policy scope.

Challenges are not perfect humanity tests. Automation can complete them, while privacy tools, accessibility software, or broken browser environments can cause legitimate failures. Measure completion and provide a recovery path.

Retain the Reason

When a policy acts, retain the network category, source, route, contributing evidence, action, and outcome. “Anonymous IP” is too vague for support or incident review.

The record should show whether the deciding factor was proxy use, an exposed credential, failure velocity, a new device, a route sequence, or several observations agreeing. That evidence lets the team tune the control without adding broad exceptions that erase protection.

Privacy and security are not opposing verdicts attached to an address. They are requirements the application has to handle at the same time.

What a Residential Proxy Decision Log Should Contain

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

A log line that says proxy=true is intelligence. It is not a decision record.

When a customer asks why a login was challenged, a fraud analyst reviews an account event, or an engineer tunes a rate limit, the team needs to reconstruct what the control knew and what it did. A timestamp, IP address, and final risk score cannot answer that on their own.

Peakhour Residential Proxy Detection keeps the proxy result inside the request decision with IP, credential, device, behaviour, and route context. The record should preserve that connection without becoming an indiscriminate collection of personal data.

Record the Request Being Judged

The event comes first. The detector explains one part of it.

Useful request fields include:

observed_at
request_id and trace_id
service, host and route class
HTTP method
response status
account, tenant, session or API-key reference where permitted
edge location and origin target
cache outcome and whether origin was reached

Avoid logging secrets, complete session tokens, passwords, payment data, or unrestricted request bodies. The OWASP Logging Cheat Sheet recommends excluding or masking access tokens, authentication passwords, sensitive personal data, and other values whose collection creates more risk than operational value.

Use stable references where the investigation needs continuity, and keep their purpose and retention bounded.

Keep Signal Provenance

The value of a signal depends on how it was produced.

For proxy and network evidence, retain:

proxy_result and category
detector or feed name
detector version or dataset time
network type, ASN and country
client IP source and trusted forwarding hop
fingerprint method, version and capture point
browser or device evidence source

A fingerprint without a method and capture point cannot be compared safely. A country value without a source and observation time is difficult to audit after data changes. A forwarded IP taken from an untrusted header should never have reached policy in the first place.

Flattening every input into one number leaves the analyst with a threshold and no explanation. Retain the factors that moved the score.

Record the Policy and the Action

The event should identify the control that made the decision:

policy_id and revision
policy owner
mode: monitor or enforce
matched conditions
threshold and current counter state
selected action
action reason code
expiry or review date

Reason codes should be stable enough to aggregate. Free-text analyst notes can add context, but they should not be the only explanation.

The action field needs more detail than blocked=true. Distinguish allow, log, challenge, rate limit, deny, route, and step-up outcomes. For a limit, keep the key class and interval without exposing sensitive raw values. For a challenge, record whether it was presented, completed, failed, expired, or abandoned.

Connect the Decision to Its Outcome

Security controls are judged by what happened next.

Join the decision to:

successful login, signup, reset, checkout, or API completion;
authentication failure and account lockout;
challenge completion and abandonment;
429, deny, or step-up response;
origin request avoided or origin work created;
support case, analyst disposition, or confirmed incident where available;
policy rollback or exception.

This is how a team distinguishes attack reduction from customer suppression. If challenges rise and successful account recovery falls, the proxy policy may be adding friction in the wrong place.

NIST SP 800-92, the Guide to Computer Security Log Management, treats log management as a lifecycle of generating, transmitting, storing, analysing, and disposing of data. That lifecycle matters here. A detailed event that nobody can query, retain safely, or delete on schedule is not operational evidence.

Metrics Should Lead to a Decision

For an enforcement platform, useful measures should connect signals to route outcomes:

proxy prevalence by route and action;
percentage of proxy-labelled traffic allowed, challenged, limited, and blocked;
challenge completion for proxy and non-proxy cohorts;
legitimate transaction completion after action;
confirmed abuse caught with and without a proxy signal;
false-positive and analyst-overturn rates;
origin requests and application cost avoided;
time from observation to policy change;
rules past their review date.

A count of “risky sessions detected” is hard to act on. A rise in residential-proxy password-reset attempts with low challenge completion and repeated account failures can justify a route-specific change.

A Minimal Event

A compact decision record might resemble:

{
  "request_id": "req_...",
  "route_class": "account_recovery",
  "proxy": {"result": true, "category": "residential", "source": "resip"},
  "fingerprint": {"method": "ja4", "version": "pinned", "capture": "client_edge"},
  "credential_state": "exposed_match",
  "recent_outcome": "repeated_failure",
  "policy": {"id": "recovery-risk", "revision": 7, "mode": "enforce"},
  "action": "step_up",
  "reason_codes": ["residential_proxy", "exposed_credential", "failure_velocity"],
  "outcome": "pending"
}

The exact schema will differ by application. The contract should not: current request, signal provenance, policy revision, selected action, and measurable outcome.

The schema is ready when a support engineer can explain a challenge, an analyst can reconstruct an account event, and the policy owner can measure the result without opening a second system. Anything collected beyond that needs a stated security purpose and retention period.

Keep Your CDN. Add Proxy and Bot Decisions at the Edge.

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

Security projects often begin with a false choice: replace the current CDN or accept the controls it already provides.

Real environments are messier. A business may have a long-term CDN contract, cloud-specific routing, established cache rules, a migration freeze, or applications that cannot all move together. The security problem still exists. Residential proxy traffic, credential stuffing, scraping, API abuse, and Layer 7 floods do not wait for a platform consolidation programme.

Peakhour Bring Your Own Edge supports two first-class paths: Peakhour Edge can be the delivery layer, or Peakhour intelligence can operate alongside the edge provider already in place. The product value is not the diagram. It is retaining one decision model for request context, policy, action, and evidence in either deployment.

Decide Where the Authoritative Observation Happens

An application behind a CDN sees a connection from the CDN, not necessarily the original client-facing connection. That affects IP provenance, TLS fingerprints, geography, and rate counters.

Before adding another control, map the path:

client → existing edge → Peakhour decision point → origin

or:

client → Peakhour Edge → origin

For every field used by policy, record where it was observed and who is allowed to set it. Client-supplied copies of forwarding or fingerprint headers must be removed at the trusted boundary. The authoritative edge can then set the value passed downstream.

This is not bookkeeping. A rate limit built on a spoofable forwarded address is a client-controlled rate limit. A TLS fingerprint calculated at origin may describe the intermediary rather than the browser. Provenance determines whether the signal can safely change an action.

Keep Policy Close to the Consequence

A decision point earns its place only if it can still protect the route. It needs to prevent avoidable origin work, slow repeated behaviour, challenge an interactive browser, block a confirmed attack, or preserve a clean path during a flood.

Peakhour combines IP intelligence, residential proxy detection, fingerprints, credentials, route behaviour, bot state, rate thresholds, and WAAP findings in that request path. The action can be allow, log, challenge, rate limit, or block. The existing CDN can remain responsible for the delivery work it already does well.

This matters because enrichment without enforcement creates a timing and ownership gap. A lookup result delivered after the application has rendered a page, queried a database, or changed account state may still help an investigation. It did not protect that request.

Network intelligence is useful on account creation, login, and password-reset routes when the signal remains connected to the request. Peakhour carries that context through to route-specific action and retains the outcome.

Migrate a Decision, Not the Whole Estate

A staged deployment can begin with one abused route:

Observe the request at the trusted boundary.
Forward or derive the fields required by the policy.
Run the new decision in monitor mode.
Compare it with current CDN and origin outcomes.
Apply one reversible action.
Expand only after false positives and operational ownership are understood.

Login, account creation, search, scraping targets, and expensive API operations are good candidates because their behaviour is measurable and their business consequence is clear.

Duplicating every rule in two systems is not a migration strategy. Decide which layer owns each action, how conflicts are resolved, and which record is authoritative. A request should not be challenged twice because two providers reached the same conclusion independently.

Preserve Cache and Origin Context

Bot and proxy decisions affect more than authentication. Scrapers and Layer 7 floods consume cache, transformation, application, and origin capacity.

A useful decision record can include:

cache status and whether the request reached origin;
route and request cost class;
proxy, IP, fingerprint, credential, and bot evidence;
rate-limit state and selected action;
response status and origin health;
policy revision and enforcement point.

That joined record shows whether a control actually protected capacity. Blocking more requests is not inherently better. Serving clean cache hits while throttling expensive automated misses may produce a stronger outcome than a broad deny rule.

Make the Trust Boundary Explainable

NIST's Zero Trust Architecture frames access around explicit resource decisions rather than implicit trust in network location. The same discipline helps at an application edge: evaluate the request from current evidence, enforce a resource-specific policy, and retain enough information to explain the decision.

An existing CDN is not an obstacle to that model. An undefined trust boundary is.

Use the delivery reality you have. Identify the client-facing observation point, choose the routes where better context can change an outcome, and assign policy ownership. Move delivery layers when the operational case supports it—not because a security feature forced an all-or-nothing migration.

Credential Stuffing Through “Clean” Residential IPs

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

The login came from an Australian consumer ISP. The address had no bad reputation and submitted one password. Viewed alone, the request barely deserved a second look.

Across the account population, the same client pattern was trying credentials against one user after another while the source addresses changed. Residential proxy networks make that distribution cheap: each exit stays below a simple threshold, the geography looks plausible, and the campaign moves before an address develops a history.

That is what the operator is buying when an exit is sold as “clean”: borrowed trust from the network and the people who normally use it. The application has to find continuity somewhere other than the address.

The Credential Is Only the Start

The OWASP Credential Stuffing Prevention Cheat Sheet recommends layered defences because no single control reliably separates every legitimate login from automated reuse. MFA, breached-password checks, device and connection signals, rate limits, and user notifications address different parts of the problem.

At the edge, the request already carries several useful facts:

the login route and response outcome;
the account or username being attempted;
whether the credential is known to be exposed;
residential proxy and broader IP context;
network and browser fingerprint cohorts;
device and session history where available;
recent attempts against this account and from this client pattern;
what the client does before and after the login request.

Peakhour Breached Credential Scanning scores credential exposure beside proxy use, IP reputation, device history, behaviour, and login context. A breached match is not an automatic conviction. People reuse exposed passwords without knowing it. The match becomes urgent when it appears inside an active attack pattern.

Count Across More Than the Address

An IP-only login limit still protects against crude repetition. It sees one slice of the campaign.

Credential stuffing needs counters that see both sides of the distribution:

per account:     failed logins across all network sources
per cohort:      failed logins across rotating IPs
per credential:  exposed match plus repeated failure or success
per campaign:    shared route, timing and client shape across accounts

These counters answer different questions. A per-account limit protects one user even when every attempt comes from a new address. A fingerprint-cohort limit exposes a tool working through many accounts. A breached-credential match raises the cost of accepting an otherwise ordinary-looking login.

Avoid permanent lockouts based only on attack traffic. They can be turned into a denial-of-service mechanism against known users. Throttling, temporary holds, step-up verification, and user alerts usually offer safer recovery paths.

Watch the Whole Account Journey

Stopping at the login form creates a blind spot. A successful credential-stuffing attempt may move immediately to:

token issue and refresh;
email or phone change;
password reset and MFA recovery;
stored payment, wallet, loyalty, or gift-card access;
address changes and checkout;
creation of new API credentials or trusted devices.

Our article Credential Stuffing Does Not Stop at the Login Form covers those post-authentication routes. The important operational point is continuity: the same risk evidence should remain available when the session reaches a high-consequence action.

A login accepted after a breached-credential match and residential proxy signal may still be allowed, but the session should not become fully trusted merely because the password worked. A recovery-email change or stored-value transfer can require stronger evidence.

“Clean” Is a Property of the Dataset

Security teams often say an IP is clean when it is absent from known abuse and proxy lists. That is a statement about current knowledge, not the connection's owner or purpose.

Google's 2026 IPIDEA disruption report described millions of devices being removed from an available proxy pool and many tracked threat groups using the exits. Google also found multiple SDK brands and reseller relationships connected to shared infrastructure.

The lesson is not that every unlabelled residential address is hostile. It is that a negative lookup cannot carry the decision. Freshness, private supply, reseller overlap, and device churn create a period in which the request arrives before the label.

Peakhour's Residential Proxy Detection evaluates the live request and places the result inside the wider account decision. Browser evidence can add context, while login APIs still receive network, credential, route, rate, and outcome controls without depending on JavaScript.

Apply Friction Where the Consequence Changes

For login and account routes, policy might respond like this:

Allow a familiar session with no adverse credential or behaviour evidence.
Log a residential proxy result on a low-risk or first-seen login.
Rate limit distributed failures across the account and client cohort.
Challenge when proxy use, an exposed credential, and unusual device or route behaviour agree.
Require step-up verification for recovery, payment, or account-control changes.
Block a confirmed automated campaign with bounded route and policy scope.

Measure successful login and recovery completion beside attack reduction. A control that suppresses failures by preventing real customers from signing in is not a successful account-protection policy.

Treat “clean” as a statement about the dataset at that moment. Make the account decision from the credential, client, route, and recent outcomes that arrived with the address.

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.

Residential Proxy Detection for APIs Without JavaScript

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

A mobile application posts directly to a login API. No page is rendered and no browser script runs. The route still needs to recognise residential proxy use and repeated automation before it accepts a credential or creates expensive origin work.

The same constraint applies to partner integrations, backend services, command-line clients, and machine-to-machine workloads. A detection that begins only after a client-side collector runs leaves those routes with a thinner control.

Peakhour Residential Proxy Detection evaluates the request without making JavaScript a precondition. When a browser is present, browser and device evidence can strengthen the decision. When it is not, the control still has network, protocol, identity, route, rate, and outcome context to work with.

The Route Sets the Policy

An API is not one security surface. A public product query, a login mutation, a password-reset endpoint, a payment instruction, and an administrative export have different costs and different identities.

The OWASP API Security Top 10 separates risks such as broken object authorisation, unrestricted resource consumption, sensitive business flows, and inventory failures because the route's purpose matters. Proxy use does not remove that context. It makes route-aware controls more important.

Before deciding how to use a proxy result, document:

the operation and its business consequence;
whether it is authenticated;
the account, tenant, token, API key, or object identity available;
expected request and response shapes;
the application work created by one call;
normal error and retry behaviour;
whether the client is interactive or machine-to-machine.

A residential exit calling a public, cacheable endpoint may be ordinary. The same exit cycling through reset tokens or forcing expensive GraphQL operations deserves a different response.

What the Server Can Observe

Server-side proxy and automation decisions can use several evidence classes.

Network context

IP intelligence can describe the ASN, network type, geography, known proxy use, hosting status, and recent reputation. These fields are useful, but none proves the original operator's location or intent.

Protocol fingerprints

TLS and HTTP characteristics can group connections that use similar client stacks. JA4 publishes both canonical and raw representations; the JA4 technical specification documents what is selected and normalised. Cisco Mercury's Network Protocol Fingerprint specification provides a structured, versioned representation of protocol observations.

These are cohort keys, not identities. A common mobile SDK may place many legitimate clients in one cohort. An automation framework can copy a popular handshake. The value appears when the fingerprint is combined with the route, identity, outcomes, and recent behaviour.

API identity and state

An API often has stronger keys than an IP address: account, token, tenant, client certificate, API key, device registration, or object identifier. A limit can follow failed behaviour across rotating addresses when one of those keys remains stable.

Request behaviour

Useful patterns include invalid route order, enumeration across objects, repeated authentication failures, token refresh without normal session history, schema deviations, abnormal response-code loops, and requests that create unusual application cost.

Capture Point Matters

Network evidence is only meaningful when its provenance is known.

If an application sits behind a CDN or reverse proxy, the TLS connection visible at origin may belong to that intermediary. A fingerprint calculated there may describe the CDN-to-origin hop, not the client. A forwarded header can carry the client-facing value, but only if the boundary strips untrusted copies, sets the authoritative field, and records the collector and version.

Keep fields such as:

capture:      client-facing edge
method:       ja4
version:      pinned implementation
value:        versioned fingerprint value
source:       trusted edge collector
observed_at:  timestamp

Without that provenance, two equal hashes may describe different capture points. The policy cannot safely compare them.

Use Composite Limits

An IP-only limit is easy to distribute around. A single global fingerprint limit can be just as dangerous because it may group a large legitimate population.

Build the key for the route:

login: fingerprint + account + failed outcome
API:   fingerprint + tenant + operation
reset: account + route + proxy state
query: API credential + cost class

Use only the fields that preserve the behaviour you are trying to count. Too few fields mix unrelated users. Too many divide the campaign into invisible buckets.

When a limit is reached, return a predictable response. RFC 6585 defines HTTP 429 for too many requests and permits a Retry-After header. That does not solve abuse by itself, but it gives legitimate clients a protocol they can handle and gives operators a clear outcome to measure.

JavaScript Is Additional Evidence

A browser that runs JavaScript is not necessarily human. Automation can execute scripts, preserve cookies, complete challenges, and reproduce browser behaviour. Conversely, privacy tools, accessibility software, content blockers, and broken client environments can interfere with collection.

Browser evidence can improve the request decision. Its presence is not proof of legitimacy, and its absence is not proof of abuse.

For Peakhour, the core decision can run for direct API traffic. Optional browser signals add context on interactive routes. Both feed the same action model: allow, log, challenge where appropriate, rate limit, or block, with the reason retained.

Deploy One Route First

Choose one API route with a known abuse problem. Record proxy state, network category, fingerprint method and capture point, API identity, request outcome, response code, and application cost. Observe enough traffic to understand normal clients and shared cohorts.

Then add one reversible policy. For example, rate limit failed logins across account + fingerprint when residential proxy use and abnormal failure velocity occur together. Track successful logins, false positives, 429 responses, origin load, and support cases before expanding it.

This first policy should leave the team with a clear comparison: what the API saw before the new evidence, which requests received a different action, and whether legitimate completion or origin load changed. That result is more useful than trying to recreate a browser check around every API call.

A Proxy Flag Is Not a Security Policy

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

At Peakhour, a residential proxy match changes how much trust we place in a request. It never selects the action on its own.

The match tells us that the network presenting the traffic may not be where the operator is sitting. Whether that matters depends on what the request is trying to do, what else is known about the client, and the cost of getting the action wrong. Treating a proxy label as policy collapses those questions into one bit. The rule becomes easy to configure and hard to operate.

Residential proxy detection therefore sits inside the live request decision beside IP reputation, credentials, device history, network fingerprints, behaviour, route sensitivity, and recent outcomes. It changes the level of evidence we require.

The Same Signal Means Different Things on Different Routes

Consider three requests from the same residential proxy exit:

A visitor opens a cached product page.
A client tries one password against 200 accounts.
An authenticated user changes the recovery email on a high-value account.

The network fact is identical. The consequences are not.

The first request may need no action beyond logging. The second has a pattern consistent with credential stuffing and needs a shared limit or block. The third may justify step-up verification because the action can transfer control of an account. A site-wide proxy deny rule misses those distinctions.

This is also why a global risk score can be frustrating in production. A score can help rank events, but the operator still needs to know what raised it and which action is proportionate. Peakhour's concern is where that context meets enforcement: on the request path, before origin work and account state changes occur.

Residential Does Not Mean One Person

Public IP addresses are weak identity keys even when no proxy is involved. Carrier-grade NAT allows many subscribers to share address space; RFC 6598 reserves a shared range specifically for that purpose. Households, offices, mobile networks, privacy services, and public Wi-Fi also put unrelated users behind common addresses.

A residential proxy complicates the picture further. The address belongs to a real consumer network, but the request may have originated elsewhere. A clean reputation may mean the exit is new. A poor reputation may reflect one abusive user while ordinary subscribers share the same public address.

This cuts both ways:

Absence from a proxy list is not proof that the request is direct.
Presence on a proxy list is not proof that the request is malicious.

Google's 2026 disruption of the IPIDEA network showed the scale of the timing problem. Google identified hundreds of Android applications and thousands of Windows binaries connected with the proxy infrastructure, and observed many tracked threat groups using its exits. The investigation also found multiple SDK brands and reseller relationships feeding shared infrastructure. The details are in Google's IPIDEA disruption report.

A provider label or yesterday's reputation cannot carry the whole decision.

Build the Decision from the Request Outward

A workable policy starts with the route.

For each protected route, record:

what the request can read, change, or spend;
whether it creates expensive application or database work;
which identity is available, such as account, session, API key, or none;
whether an interactive challenge is possible;
what a false block would cost the user and the business;
which recent outcomes make repetition suspicious.

Then add the network and client evidence. A residential proxy result becomes more useful when it agrees with other observations: a breached credential, an unseen device, a fingerprint shared across rotating IPs, failed outcomes across many accounts, an invalid route sequence, or an abnormal request rate.

The policy can then choose among real actions:

Allow when the route is low risk and the session is otherwise consistent.
Log when the signal is new or the cost of intervention is higher than the current evidence supports.
Challenge when the client can provide more evidence and there is a safe recovery path.
Rate limit when repeated behaviour is the problem, especially across accounts, fingerprints, API credentials, or costly operations.
Block when the evidence is strong, harm is current, and narrower controls cannot protect the route.

Peakhour evaluates that context in the request path. Browser signals can add evidence when a browser is present, while API traffic can still be assessed without requiring JavaScript. The selected action and its inputs remain part of the decision record rather than disappearing into a standalone lookup.

Scores Need Reasons and Actions Need Owners

A security team should be able to answer three questions after a request is challenged or blocked:

Which observations changed the decision?
Which policy revision selected the action?
Did the action protect the route without breaking legitimate completion?

If the only retained field is risk_score: 87, review becomes guesswork. Keep the useful components: route, proxy result, IP category, fingerprint provenance, account or token state, recent failures, threshold state, action, policy revision, and origin outcome.

Every enforcement rule also needs an owner and an expiry condition. Proxy networks change. Client populations change. A rule created during an incident should not become permanent merely because nobody knows why it exists.

Start in observation mode on one sensitive route. Measure ordinary variation, proxy prevalence, successful completion, challenge outcomes, and false positives. Move to enforcement when the evidence supports a specific action. Roll back when the customer cost exceeds the risk reduction.

On a sensitive route, the proxy match may justify corroborating evidence or a reversible action. On a low-risk route, logging may be enough. In both cases, the team should be able to show which facts changed the decision and what happened afterwards. That is how proxy intelligence becomes an operable control rather than another label in a feed.

How Bandwidth Sharing Feeds Residential Proxy Networks

2026-08-01T10:00:00+10:00

A request arrives at your login page from a normal Australian broadband connection. The IP belongs to a consumer ISP. The location is plausible. It is not on a data centre list or a public proxy feed.

What the request does not tell you is who controls it.

The connection may belong to a real customer. It may also be the exit point for somebody on the other side of the world who bought access to it by the gigabyte. The device supplying that access could be running a bandwidth-sharing app, carrying a monetisation SDK inside an unrelated utility, compromised by malware, or sold with unwanted software already installed.

That supply chain is why residential proxy traffic is difficult to handle. The IP address is real. The trust attached to it is not.

Bandwidth Sharing Turns Connectivity Into Inventory

Bandwidth-sharing software lets a third party route traffic through someone else's internet connection. At the destination, the traffic leaves through the participant's residential or mobile IP address rather than the operator's original network.

The commercial pitch is usually simple: share unused bandwidth and earn a little money, or let an app developer earn revenue without showing more advertising. There are legitimate and clearly disclosed versions of that arrangement. The problem is that the same machinery also works when the disclosure is vague, the SDK is hidden inside an unrelated app, or the device owner never agreed at all.

Once enrolled, the device becomes supply. A proxy provider or reseller can package that supply by country, city, ISP, session duration, or available capacity. A buyer does not need to know whether the exit came from an informed participant, an obscure clause in an app's terms, or a compromised device. They pay for the route.

For the website receiving the request, those sourcing distinctions are mostly invisible. It sees a consumer IP address and has to decide whether the request belongs to a customer.

There Is More Than One Way Into the Pool

Residential proxy networks are not built from a single source. Their capacity can come from several different arrangements:

Explicit bandwidth-sharing apps. The user installs software whose stated purpose is to sell or share some of their connection.
Monetisation SDKs. A developer embeds third-party code in a game, utility, browser extension, VPN, or desktop application and is paid for active devices or transferred data.
Trojanised applications. A useful-looking app performs its advertised function while quietly enrolling the device as a proxy exit.
Preloaded or setup-time software. Cheap streaming boxes and other connected devices can arrive compromised or download a backdoor when first configured.
Post-compromise installation. An attacker exploits a server or endpoint, then installs otherwise legitimate bandwidth-monetisation software to generate recurring income.

These paths sit on a spectrum from deliberate participation to outright compromise. They produce a similar result for the destination service: third-party traffic exits through an address that looks residential.

The Quiet Payload Is Often the Point

The most revealing development is not a new proxy protocol. It is the use of legitimate proxyware as a payload.

In 2025, Palo Alto Networks Unit 42 documented a campaign that exploited vulnerable GeoServer instances and deployed a legitimate passive-income app and SDK. The SDK used by the attacker was identical to the vendor's official version. Instead of encrypting files or consuming enough CPU to announce itself like a cryptominer, the software quietly monetised the victim's bandwidth.

That changes the economics of a compromise. The attacker does not need to sell access once or deploy noisy malware immediately. A compromised machine can produce a smaller recurring return while its connection is resold. Legitimate code also gives endpoint security a harder judgement to make: the binary may be real, while the installation and use are unauthorised.

This is not only a server problem. In 2025, the FBI warned about BADBOX 2.0, which affected Android-based TV boxes, projectors, digital picture frames, aftermarket vehicle systems, and other connected devices. Some were compromised before purchase; others downloaded backdoored applications during setup. Once connected to a home network, those devices could become part of botnet and residential proxy activity.

An inexpensive box under a television is attractive infrastructure. It stays powered on, sits behind a real household connection, and rarely receives the scrutiny given to a laptop or phone.

2026 Made the Scale Harder to Dismiss

In January 2026, Google said it had disrupted the IPIDEA residential proxy network through legal action, platform enforcement, and industry coordination.

Google's investigation found more than 600 Android applications across multiple download sources connecting to the network's command infrastructure. It also identified 3,075 Windows binaries and described millions of devices being removed from the available proxy pool. During one seven-day period, Google observed more than 550 tracked threat groups using IPIDEA exit nodes to obscure activity including password spraying and access to SaaS and on-premises systems.

Those numbers matter, but the structure matters more. Google found different SDK brands feeding shared infrastructure, along with overlaps between proxy exit pools created by reseller and partnership arrangements. A provider name is therefore not a reliable boundary. The device supplying an exit, the company marketing the SDK, the reseller selling access, and the operator using the connection may all be different parties.

Taking down one set of domains can disrupt a network. It does not remove the incentive to rebuild the supply somewhere else.

Consent Is Not a Security Verdict

Proxy providers often frame sourcing as a consent question: did the device user agree to share bandwidth? That is important, but it is not enough.

There are at least three separate parties whose interests matter:

The device user, who should understand that strangers can send traffic through their device and IP address.
The network owner or ISP, whose service terms and security controls may not allow resale or third-party routing.
The destination service, which never agreed to treat paid proxy traffic as a normal local customer.

A tick buried in a long terms-of-service document is weak evidence that the first party understood the arrangement. It says nothing about the other two. Even genuinely informed consent only explains how an exit joined the pool. It does not make the buyer's login attempt, checkout request, scrape, or password reset benign.

Google Play has drawn this boundary since August 2019, when it added proxy services as an example under its Device and Network Abuse policy. Apps may facilitate proxy services to third parties only when proxying is their primary, user-facing core purpose. Consent does not turn a hidden proxy SDK inside an unrelated game or utility into the app's core purpose.

The rule is not new, and it did not eliminate SDK-sourced proxy capacity. More recent Android controls make persistent background activity easier to scrutinise, while operations such as Google's 2026 IPIDEA disruption show what stronger enforcement can remove from a pool. Platform action can reduce supply. It still cannot establish the intent behind every request that has already reached a website.

Google's later NetNut action made the same limitation easier to measure. Our comparison of the IPIDEA and NetNut residential proxy takedowns follows what happened to the infrastructure, the suppliers and the destination risk.

Why IP Reputation Arrives Late

An IP reputation database can identify known proxy exits. It cannot reliably answer who is controlling a connection right now.

Residential pools change quickly as phones move between networks, apps open and close, devices reconnect, and operators shift infrastructure. One public IP can also represent many unrelated people behind carrier-grade NAT. A clean label may mean the exit is new. A bad label may describe one abusive session while legitimate users share the same address.

This creates two predictable errors:

Trusting a residential address because it is absent from a proxy list.
Blocking an address so broadly that ordinary users sharing the connection are caught with it.

The answer is not to discard IP intelligence. It is to stop treating it as identity.

Detect the Relay, Then Judge the Request

The sourcing story explains why a request may be suspicious. It does not decide what your application should do.

Useful detection combines several kinds of evidence:

Per-connection network and protocol fingerprints that can reveal a relay even when the IP looks ordinary.
Browser, device, TLS, and HTTP characteristics that do not agree with one another.
Repeated behaviour that survives IP rotation, such as credential testing across many accounts or identical request timing.
Route and account context, including whether the request is browsing a public page, attempting login, resetting a password, changing payment details, or calling an API directly.
Recent outcomes such as failed authentication, challenge failure, unusual token use, or high-risk account changes.

This is where residential proxy detection belongs: inside the request decision, beside IP intelligence, fingerprints, behaviour, credentials, and account state.

A proxy signal on a public article may only be worth recording. The same signal on a login attempt with a first-seen client and failures across several accounts may justify a challenge or tighter rate limit. On a password reset or payment change, it may support step-up authentication or a block.

The action should follow the evidence and the cost of being wrong.

What Security Teams Should Change

For application and fraud teams, the practical response is straightforward:

Map the sensitive web and API routes where proxy use should change a decision.
Measure residential proxy traffic before enabling broad enforcement.
Key rate limits on accounts, tokens, fingerprints, routes, and outcomes as well as IP addresses.
Keep allow, monitor, rate-limit, challenge, and block as separate actions.
Preserve a decision record so security, fraud, and support teams can explain why a request was handled differently.
Review false positives by network type, especially mobile carriers and CGNAT-heavy ISPs.

Endpoint and network teams have a related job. They should inventory bandwidth-sharing and proxy software, review monetisation SDKs, monitor unusual long-lived outbound connections, restrict unapproved software on managed devices, and treat cheap connected hardware as part of the network attack surface rather than as an appliance that can be forgotten after setup.

The Address Is Real. The Assumption Is Not.

Bandwidth sharing has made an old security shortcut less defensible. Residential no longer means local, human, or trustworthy. It describes where traffic leaves the internet connection, not who initiated it or what they intend to do.

Some proxy exits are knowingly shared. Some are poorly disclosed. Some are compromised. A destination service usually cannot see that history, and it should not need to settle the sourcing dispute before protecting an account or API.

Detect the relay where you can. Combine that signal with what the request is doing. Then apply only the friction the evidence supports.

For more background, read How Residential Proxy Networks Are Formed and How Residential Proxies Changed API and Account Abuse.

How to Tune F5 BIG-IP Advanced WAF

2026-07-29T10:15:00+10:00

An F5 policy has three separate controls between a signature match and a blocked request.

The policy has an enforcement mode. Each violation has Learn, Alarm and Block settings. Each signature or policy entity can also be in staging.

Record all three before changing the policy.

Start a new policy in Transparent mode

Set a new policy, a major policy revision or a newly protected application to Transparent under Security > Application Security > Policy Building > Learning and Blocking Settings.

Transparent mode allows requests through while the policy records violations. F5 normally generates a learning suggestion when the violation has Learn enabled. Save the change and select Apply Policy.

Blocking mode behaves differently. A request is blocked only when the policy is in Blocking mode, the violation has Block enabled and the matching entity or signature has left staging. F5 documents the interaction between enforcement mode, violation actions and staging.

F5 calls the staging window the Enforcement Readiness Period. The default is seven days. During that period, the policy does not enforce staged signatures or entities. Configure learning and logging to capture their matches. The policy settings guide explains Transparent mode and enforcement readiness.

Seven quiet days prove only that the traffic seen during those days was quiet. Include month-end jobs, imports, account recovery, administration, checkout, API writes and other flows that ordinary browsing misses.

For an established blocking policy, stage the signatures or entities affected by a change. The rest of the policy can remain in force while those changes collect traffic.

Log staged signature matches

The default logging profile records illegal requests. A staged attack-signature match can be allowed and therefore needs an explicit logging choice.

Create or edit an application-security logging profile under Security > Event Logs > Logging Profiles. Set the request filter to Illegal requests, and requests that include staged attack signatures. Associate the profile with the virtual server that runs the security policy.

F5 supports local and remote logging profiles. Local logging competes for resources on the BIG-IP system; remote logging can send CSV, key-value or CEF records to a reporting system. F5 documents the logging destinations, staged-signature filter and virtual-server association.

Keep these fields for each investigation:

security policy and virtual server;
support ID and event time;
hostname, URL and method;
violation name;
attack-signature ID and attack type;
parameter, cookie, header or request area that matched;
matched data;
violation rating;
enforcement mode and staging state;
application response.

The support ID ties a user-facing block page to the stored request. The violation rating runs from 1 to 5. F5 describes 1 as most likely a false positive and 5 as most likely an attack. Use the rating to order the work, then read the request and ask the application owner what the input means. F5 lists the request details and explains violation ratings.

Group events by policy, violation, signature ID, URL, method and named request field. A signature firing in comment on POST /api/tickets needs a different review from the same signature firing in an authentication parameter.

Request logs may contain credentials, personal information and customer text. Mark account numbers, tokens and other secrets as sensitive parameters so F5 masks their stored values. F5 documents the sensitive-parameter setting and log masking.

Read the request behind each learning suggestion

Traffic Learning turns observed violations and new entities into proposed policy changes. Open Security > Application Security > Policy Building > Traffic Learning, select the policy and inspect the requests attached to each suggestion.

Accept Suggestion changes the policy. Treat it like any other configuration change.

Manual learning waits for an operator to accept a suggestion. Automatic learning can apply most suggestions after F5 has seen enough traffic, sessions, time and source addresses. Manual learning keeps each relaxation visible while a new or sensitive application is being tuned. F5 describes Manual, Automatic and Disabled learning modes.

A busy suggestion can still describe a busy attack. Confirm that the requests reached the expected application path, parsed successfully and produced the expected business result.

Ask the developer who owns the endpoint:

what values the field accepts;
how the application parses them;
whether the value is stored, rendered or executed;
which server-side validation protects it;
whether the field has the same meaning on every URL;
which test request reproduces the legitimate match.

Accept a suggestion only after its scope matches the application behaviour. Ignore removes a suggestion from the normal Traffic Learning view; it does not repair a false positive. F5 lets operators accept, delete or ignore suggestions and inspect the requests behind them. The Traffic Learning guide documents those actions.

Check how F5 parsed the body

A JSON request treated as unparsed content produces different signature targets from a JSON request split into named parameters.

Check the allowed URL and its Request Body Handling setting. F5 can parse form data, JSON or XML, or scan an unparsed payload with content and value signatures. A JSON or XML setting also names the content profile used for validation. F5 lists the request-body handling modes in its allowed-URL documentation.

Match the profile to the content type the application accepts. Associate the profile with the correct URL or parameter. Reproduce malformed bodies with the same bytes because the application and F5 may recover from parser errors differently.

Use explicit parameters for fields that need their own policy. F5 supports global, URL and flow parameters, and applies the most specific definition first: flow, then URL, then global. A free-text comment field on one endpoint usually belongs at URL level.

The Ignore value parameter type removes parameter-based signature checks from that value while leaving other relevant signature checks active. A one-signature override removes less inspection. Reserve Ignore value for data the application genuinely does not interpret.

Put the exception on the field or URL that needs it

F5 exposes several scopes for an attack-signature override:

one signature on one URL parameter;
one signature on one named cookie;
one signature in a content profile;
one signature on an allowed URL;
one signature across the security policy.

Choose the scope that matches the application.

For a false positive in comment on /api/tickets, define comment as a URL parameter and disable the signature for that parameter. The same signature continues to inspect other parameters and other URLs.

F5 also allows a signature override on an allowed cookie. Use that control when a named analytics or session-related cookie carries the legitimate value. Cookie names and values have their own configuration, so record which part produced the match.

A content-profile override applies wherever that JSON, XML or plain-text profile is associated. Check every URL and parameter using the profile before changing it. F5 documents signature overrides and associations for JSON profiles.

An allowed-URL override disables the selected signature for the whole URL. Every request field on that URL receives the exception. F5 describes URL-level signature overrides as a common operation and marks overridden signatures in the policy list. The allowed-URL and cookie procedures describe their attack-signature overrides.

Disabling a signature at policy level removes it from the whole application-security policy. Use that scope only when the signature is irrelevant to every request covered by the policy.

Record the signature ID, signature revision, URL, parameter or cookie, matched examples, application owner and protections that remain.

Apply, synchronise and test the policy

Saving an edit does not put it into the active policy. Select Apply Policy, wait for the operation to finish and confirm that the virtual server still has the intended application-security and logging profiles.

Synchronise the change to the peer device when the BIG-IP pair uses manual ConfigSync. F5 can display a sync reminder after policy changes in a high-availability configuration. The Advanced WAF preferences guide describes Apply Policy confirmation, change logging and the ConfigSync reminder.

Replay:

the original legitimate request;
the same value in another parameter;
the same value on another URL;
a safe signature test in the excluded field;
the safe test in a neighbouring field;
malformed and oversized versions of the request;
normal application traffic.

The legitimate request should complete without the false-positive event. The safe test in the excluded scope shows the inspection removed by the exception. Neighbouring fields and URLs should still produce the expected signature event.

Check the support ID, signature ID, staging state and application response after every replay.

Compare and export the policy

Use Security > Application Security > Security Policies > Policy Diff to compare the tuned policy with the earlier policy or a staging copy. F5 can compare active, inactive and exported policies.

Export the policy before a large tuning session, signature update or BIG-IP upgrade. A readable XML export supports review and version control; a binary policy archive preserves a restorable copy.

Compact XML omits attack-signature staging state and omits some settings that remain at their defaults. Use the full XML format when the review needs to show staging. Export user-defined attack signatures separately because a policy export contains their sets without the signatures themselves. F5 documents Policy Diff and the export-format limits.

Stage signature updates and application releases

F5 Live Update places newly added attack signatures in staging. Updated signatures follow the policy's Updated Signature Enforcement setting. Review that setting before installing an attack-signature update. F5 documents the post-update staging behaviour.

Keep signature staging enabled during the observation period. Review each high-volume match, then enforce the signatures that have clean traffic and tested application flows.

Run the same process after an application release that changes:

public URLs or methods;
parameter names or value types;
JSON, XML, GraphQL or multipart bodies;
cookies and headers;
uploads;
authentication and account flows.

Tell the application team which policy changes are waiting in staging. The application team knows whether a new field belongs in the release.

Keep rate limiting in the DoS profile

F5 application-security policies inspect individual requests. BIG-IP Layer 7 DoS protection measures transaction rates and server latency through a separate DoS profile attached to the virtual server.

Configure rate limiting under the DoS profile when repeated traffic is the problem. F5 can rate limit suspicious source addresses, countries, URLs or a site under attack. Transparent and Blocking modes for the DoS profile control whether those conditions are reported or mitigated. F5 documents TPS-based detection, stress-based detection and request rate limiting.

Track WAF signature blocks and DoS rate limits as separate outcomes. A false-positive signature needs a policy exception. The application owner must set an acceptable rate and response for excessive legitimate traffic.

Move the policy to Blocking

Switch the policy from Transparent to Blocking after:

normal and infrequent application flows have run;
every repeated legitimate match has been classified;
each exception has the smallest supported scope;
staged entities and signatures have been reviewed;
Learn, Alarm and Block settings match the intended response;
the replay tests pass;
the active and standby devices have the same applied policy.

Move a small application or virtual server first when the deployment supports it. Watch blocked requests, application errors and business transactions together.

The blocking response includes a support ID. Keep the event long enough for support staff to find the exact request without storing customer content in the exception record.

Review the policy after each application release and signature update. Remove an override when the field, parser or application behaviour that required it has gone.

How to Tune Google Cloud Armor WAF Rules

2026-07-29T10:00:00+10:00

Cloud Armor evaluates security-policy rules by priority. The request log shows the preview rule that matched and the enforced rule that decided the request.

An allow rule at priority 100 accepts the request before a SQL injection rule at priority 1000 can inspect it. A WAF rule in preview records the action it would have taken while an enforced rule decides the request.

Preview one WAF rule

Cloud Armor preview belongs to individual security-policy rules. The configured action is recorded while policy evaluation continues to an enforced rule. Both results appear in the request log when the preview rule takes priority. Google documents this evaluation behaviour and the --preview flag.

The commands below use a global service-level security policy. Add --region=REGION to each command when working with a regional policy.

Create or update the WAF rule with a deny action and preview enabled:

gcloud compute security-policies rules create 1000 \
    --security-policy app-policy \
    --expression "evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})" \
    --action deny-403 \
    --preview \
    --description "SQLi v4.22 sensitivity 1"

Sensitivity 1 is a sensible starting point for most applications. It enables the higher-confidence signatures and usually produces less noise than higher levels. Google recommends starting new preconfigured WAF rules at sensitivity 1 and validating them in preview. The current Cloud Armor best-practices guide gives both recommendations.

Read both policy results in the request log

Cloud Armor adds its policy results to the load balancer’s per-request log. Request logging is disabled by default for new backend services, so enable it before starting the preview. Look for previewSecurityPolicy to see the preview match and enforcedSecurityPolicy to see the enforced result. The preconfiguredExprIds array contains every WAF signature that triggered the matching policy rule. Google lists the logging prerequisite and policy fields in the Cloud Armor request-logging reference.

A Logs Explorer query can isolate the preview rule:

resource.type="http_load_balancer"
jsonPayload.previewSecurityPolicy.name="app-policy"
jsonPayload.previewSecurityPolicy.priority=1000

Group the results by:

preconfiguredExprIds;
request path and method;
preview rule priority;
enforced outcome;
client or application flow;
time and release version.

Use our general WAF tuning guide to classify those repeated matches and choose the smallest safe exception.

Enable verbose logging for a short investigation when the ordinary log shows the signature but omits the input. It adds matchedFieldType, matchedFieldName and a short matchedFieldValue snippet for requests matching preconfigured WAF rules. Those snippets can contain customer or personal data. Google recommends disabling verbose logging during normal operation. The verbose-logging guide describes the extra fields and privacy risk.

Match the signature ID to the ruleset version

The name sqli-v422-stable identifies the SQL injection ruleset built from CRS 4.22. A signature inside it has the same version in its ID, such as:

owasp-crs-v042200-id942350-sqli

Use the ID written by the policy log. Cloud Armor requires an opted-out signature ID to match the ruleset version, and rejects mismatched versions. Google shows the versioned naming and requirement in its WAF tuning guide.

A ruleset upgrade can add or change signatures. Put the new version in preview, compare its matches with the enforced version and promote it after reviewing the result.

Google also publishes canary rulesets. Its recommended arrangement runs the canary at a higher priority in preview and the stable ruleset at a lower priority in enforcement. The canary records the requests it would deny while the stable rule protects the service. Google describes this stable-and-canary arrangement in its best practices.

Choose the sensitivity level first

Sensitivity levels run from 0 to 4. Choosing level 2 enables signatures at levels 1 and 2. Higher levels inspect for more patterns and tend to produce more false positives. Level 0 enables no signatures unless you explicitly opt them in. Google maps Cloud Armor sensitivity to CRS paranoia levels in the tuning documentation.

Choose a level that fits the application and the time available to investigate. A public marketing site with conventional inputs may run cleanly at a higher level. An API accepting templates or query fragments may need more work.

Keep the chosen sensitivity and exclude the named field from the affected signature.

Opt out one noisy signature

If a signature is irrelevant wherever the policy rule applies, list its versioned ID in opt_out_rule_ids:

evaluatePreconfiguredWaf(
  'sqli-v422-stable',
  {
    'sensitivity': 2,
    'opt_out_rule_ids': [
      'owasp-crs-v042200-id942350-sqli'
    ]
  }
)

The WAF rule runs every SQL injection signature enabled at sensitivity 1 and 2 except the named signature.

Use an opt-out after reviewing where the policy rule applies. A rule matching every request to a shared backend gives the exception the same reach.

Enable selected signatures at sensitivity 0

Set sensitivity to 0 when the rule needs only a few named signatures:

evaluatePreconfiguredWaf(
  'xss-v422-stable',
  {
    'sensitivity': 0,
    'opt_in_rule_ids': [
      'owasp-crs-v042200-id941150-xss'
    ]
  }
)

Cloud Armor permits opt_in_rule_ids only at sensitivity 0. Google recommends this approach when you want fewer signatures than you would otherwise opt out. The setup guide documents the constraint and provides current CLI examples.

An opt-in rule enables only the named signatures for the traffic matched by that policy rule. Record why each signature was selected and when to review the set.

Exclude the field that carries legitimate content

A request-field exclusion keeps a signature active and removes a selected input from its inspection.

Cloud Armor can exclude named header values, cookie values, query-parameter values and URIs from an entire preconfigured ruleset or selected signatures. Header, cookie and query-parameter names remain inspected when their values are excluded. URI exclusions remove the matching URI from inspection for the selected target. Google documents each field’s behaviour and available match operators.

Suppose the cookie analytics_id repeatedly triggers signature 942100. Add an exclusion to the existing SQLi policy rule:

gcloud compute security-policies rules add-preconfig-waf-exclusion 1000 \
    --security-policy app-policy \
    --target-rule-set sqli-v422-stable \
    --target-rule-ids owasp-crs-v042200-id942100-sqli \
    --request-cookie-to-exclude "op=EQUALS,val=analytics_id"

The signature continues to inspect the cookie name and every other request field, excluding only the value of analytics_id.

Request query parameters need one extra check. Cloud Armor rebuilds the URI and request line after removing an excluded query parameter. A signature that inspects the entire REQUEST_BODY continues to inspect it, so the same parameter can trigger a body-wide signature. Google calls out this behaviour in the query-parameter exclusion documentation.

A policy rule with request-field exclusions cannot use the allow action. Use the WAF’s deny action and let unmatched requests continue through the policy. This restriction appears in the current preconfigured WAF limitations.

Apply the tuned WAF rule to one route

Cloud Armor uses Common Expression Language expressions for advanced matches. Combine the route condition and WAF evaluation in one rule when an exception belongs to one application area:

request.path.startsWith('/api/messages') &&
evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})

Create a separate SQLi rule for the rest of the application and exclude /api/messages from its expression. The route is then evaluated once under the tuned rule.

!request.path.startsWith('/api/messages') &&
evaluatePreconfiguredWaf('sqli-v422-stable', {'sensitivity': 1})

Priority decides which matching rule takes effect. A smaller number has higher priority. An earlier allow rule ends evaluation for the matching request, so later WAF rules never see it. Google explains the evaluation order and demonstrates the effect of an early allow.

Replay three requests when testing route logic:

a legitimate request containing the known false-positive value;
an attack string in the excluded field;
an attack string in another field.

The legitimate request should pass. The attack string in the excluded field shows the exposure created by the exception. The attack string in another field should still trigger the WAF rule.

Set the request-body inspection limit

Cloud Armor inspects a configurable prefix of the request body: 8, 16, 32, 48 or 64 kB. The limit applies across the preconfigured WAF rules in the policy, and 64 kB is the maximum. Content after the limit can reach the backend without WAF body-signature inspection. Google documents the available sizes and provides the policy update command.

Choose the size from the requests the application accepts. Check uploads, GraphQL, JSON APIs and form submissions separately. Google supports parsed URL-encoded and JSON bodies; other content and encodings, including XML, gzip, UTF-16 and multipart form data, receive rules over raw data. The security-policy overview describes the current body parsing behaviour.

Verbose logs include inspectedBodySize, which helps confirm the active limit. Decide how the application handles larger bodies. Google suggests a separate content-length rule when the application can safely reject requests beyond the inspection limit, though Content-Length deserves the same validation you would apply to any client-supplied header.

Identify who manages the policy

Service-level backend security policies attach to backend services. Send their false positives to the team that manages the backend policy.

Hierarchical policies attach at the organization, folder or project level and flow down to projects. Send inherited false positives to the team that manages the hierarchical policy.

Creating a hierarchical security policy requires Cloud Armor Enterprise Paygo and can enrol the project automatically. Google documents the commercial requirement and ownership model in the hierarchical policy guide.

Include the matched policy name and priority in each false-positive report. Give the policy team the field, route and application behaviour needed to review the exception.

Hierarchical and service-level policies support different feature sets. Check the current feature table before moving a tuned rule between them. Google maintains the comparison in its security-policy overview.

Disable preview after reviewing the matches

Run normal traffic, scheduled jobs and important application flows through the preview rule. Classify each recurring signature and field, then disable preview:

gcloud compute security-policies rules update 1000 \
    --security-policy app-policy \
    --no-preview

Cloud Armor rule changes usually take several minutes to propagate. Watch the enforced policy outcome after the change and replay the requests used during tuning. Google lists propagation time among the preconfigured WAF limitations.

Keep the previous expression and exclusions in version control. Record the policy, priority, ruleset version, sensitivity, signature IDs, excluded fields and test requests.

How to Tune Cloudflare WAF When Rule 949110 Blocks a Request

2026-07-29T09:45:00+10:00

Rule 949110 blocked the request.

In Cloudflare's OWASP managed ruleset, 949110: Inbound Anomaly Score Exceeded checks the total score produced by earlier detections. The rules that raised the score explain the block.

Cloudflare puts that answer in Additional logs.

Start with the blocked event

Open Security > Events in the Cloudflare dashboard and filter to the hostname, path, action and time of the request.

Security Events shows traffic that Cloudflare acted on or flagged. Its top-level views group events by fields such as action, host, country and service. The sampled log beneath them contains a subset of individual security events, so a busy time range may hide the request you need. Narrowing the time range reduces sampling. Cloudflare documents the Security Events views and sampling behaviour.

Capture the details that identify the request:

Ray ID;
timestamp;
hostname and path;
method;
WAF service and action;
displayed rule ID and description;
the application result reported by the user.

One request can produce more than one security event. Keep the Ray ID and timestamp together while you follow the detections.

If the displayed description is 949110: Inbound Anomaly Score Exceeded, open Additional logs. Cloudflare places the OWASP rules triggered by that request there. The Security Events documentation describes those contributing OWASP records.

Additional logs deserve a manual check in the dashboard. Cloudflare says triggered OWASP rules shown there are absent from exported Security Events JSON. A log export containing only the final event can therefore leave out the detections that built the anomaly score. The Security Events documentation records that export limitation.

Find the rule that raised the score

Additional logs may show one contributing rule or several. Record each rule's description and Cloudflare rule ID.

The description may begin with a familiar CRS-style number. Cloudflare's API and exception controls use Cloudflare's opaque rule ID. Use the identifier displayed by Cloudflare when you configure the rule.

Group repeated matches by rule, field and route, then review each group with the application owner. A single support message containing SQL syntax may be legitimate. Different paths or different rules belong in separate investigations. The general WAF tuning guide explains how to classify each group and record an exception.

Ask the developer who owns the route:

what input the endpoint accepts;
whether the request was parsed successfully;
where the matching value is stored or rendered;
which validation runs at the application;
whether the field can carry executable syntax by design.

Choose an override or an exception

An override changes the configuration of a managed rule or ruleset across that deployment. You can change an action, disable selected rules or adjust settings such as the OWASP anomaly score threshold and paranoia level.

An exception matches a set of requests and skips selected managed rules for those requests. Its expression can use the host, URI path, method and other Cloudflare Rules language fields.

Use an override when the rule itself needs a different action across the deployment. Use an exception when a known application route needs different treatment.

Cloudflare allows exceptions to skip:

every remaining managed rule;
one or more managed rulesets;
one or more rules inside managed rulesets.

Select the contributing rule. A whole-ruleset exception removes far more inspection from the matching request. Cloudflare documents the three exception types and their order of precedence.

For a false positive confined to message creation, the expression could be:

http.host eq "api.example.com"
and http.request.uri.path eq "/v1/messages"
and http.request.method eq "POST"

Choose the Cloudflare rule ID found in Additional logs as the rule to skip.

Cloudflare skips that rule for the complete matching request. Another field on POST /v1/messages can trigger the same rule and receive the same exception. Record that consequence.

Place the exception before the managed ruleset

An exception works only on managed-ruleset execution rules listed after it in the same phase. Put the skip rule before the rule that executes the OWASP managed ruleset. Cloudflare's API documentation states that skip rules affect only later execute rules.

Cloudflare can run managed rulesets at account level on Enterprise plans and at zone level. Account-level rulesets execute before zone-level rulesets. An account-level exception affects account-level rules, while a zone-level exception affects zone-level rules. A zone exception cannot prevent an account-level rule from matching first. Cloudflare documents this scope and evaluation order.

Find the execute rule that produced the event. Add the exception at that level and before that execution. If the OWASP ruleset runs at both levels, inspect both deployments and decide which one needs the exception.

Exceptions take priority over overrides. Cloudflare records that precedence in its managed-ruleset documentation.

Test the exception through Cloudflare

Send the original legitimate request through the hostname proxied by Cloudflare. An origin-only replay bypasses the configuration you are testing.

Use a small test set:

the legitimate request on the exempt route;
the same input on another route;
a safe request that triggers the contributing rule on the exempt route;
the same test outside the exception;
normal traffic that should pass unchanged.

Check Security Events after each request. Confirm the Ray ID, action, contributing rules and final result.

The safe trigger on the exempt route shows what the exception allows. The same trigger outside the exception should still raise the contributing rule and reach 949110.

Cloudflare evaluates security products and rules in a defined sequence, and a terminating action stops later evaluation. An earlier custom-rule Block or Managed Challenge can determine the result before Managed Rules run. Cloudflare's WAF concepts guide describes this rule execution behaviour.

Set the anomaly threshold from real traffic

The OWASP anomaly threshold is the cumulative request score at which 949110 applies the configured action. Raising it moves the block point for every request covered by that deployment.

Use Security Events to see which rules contribute to normal requests before changing the threshold. A repeated false positive from one rule and one endpoint points towards an exception. A broad pattern of low-confidence detections may justify a threshold or paranoia-level review.

Cloudflare supports overrides for the full ruleset, rule tags and individual rules. Tag and ruleset overrides can also affect future rules that Cloudflare adds under those selections. Individual rule overrides target the rule IDs you chose. The managed-ruleset documentation explains these override levels.

Test a threshold change with the same care as a rule exception. It changes when 949110 acts across all covered traffic.

Record the exception and its rule IDs

Document:

the Ray IDs and event times reviewed;
the contributing Cloudflare rule IDs and descriptions;
the anomaly threshold and paranoia level;
the exception expression;
the account or zone deployment it belongs to;
its position before the managed-ruleset execute rule;
what the selected rule stops inspecting;
the developer who confirmed the application behaviour;
the requests used for verification;
the review date.

Recheck the exception after application changes and Cloudflare managed-rule updates. A new route can need different conditions. A revised rule can remove the original false positive.

Rule 949110 applies the configured action when the anomaly score crosses the threshold. Tune the rules that supplied the false-positive score.

How to Tune Azure Application Gateway WAF

2026-07-29T09:30:00+10:00

An Azure WAF false positive usually arrives as a 403 and a complaint.

Treat the 403 as the start of the investigation. The firewall log identifies the rule, the relevant part of the request and the policy that applied.

Put new policies into Detection mode

Use Detection mode while introducing a WAF policy, upgrading its managed ruleset or placing an existing application behind Application Gateway. The WAF records rule matches while every request continues to the application.

Microsoft suggests reviewing one to two weeks of traffic before returning the policy to Prevention mode. Plan and supervise that period because attacks also continue to the application. Microsoft documents this rollout in its Application Gateway WAF troubleshooting guide.

Before changing the mode, save the complete policySettings block:

az network application-gateway waf-policy show \
    --name "$WAF_POLICY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --query policySettings \
    --output json

The Azure CLI command az network application-gateway waf-policy policy-setting update rewrites the policy settings. Microsoft warns that omitting --request-body-check silently resets the setting to false. Supply the current value when switching modes, then read the policy back and verify it. The warning and corrected commands appear in Microsoft’s current troubleshooting procedure.

For a policy that already inspects request bodies:

az network application-gateway waf-policy policy-setting update \
    --policy-name "$WAF_POLICY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --state Enabled \
    --mode Detection \
    --request-body-check true

Use the value returned by the first command.

Send the firewall log to Log Analytics

Application Gateway produces access and firewall logs through Azure Monitor. Microsoft recommends the resource-specific Log Analytics tables for new diagnostic settings. WAF events then appear in AGWFirewallLogs; the older Azure Diagnostics mode writes them to AzureDiagnostics. Microsoft explains both collection modes and recommends the resource-specific tables.

Check which table receives your data before borrowing a query from another subscription.

For a resource-specific table, start here:

AGWFirewallLogs
| where TimeGenerated > ago(7d)
| where Action in ("Detected", "Matched")
| summarize
    Events = count(),
    Requests = dcount(TransactionId),
    Paths = make_set(RequestUri, 20)
  by RuleId, Message, PolicyScope, PolicyScopeName
| order by Events desc

For a workspace using the older shared table:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s in ("Detected", "Matched")
| summarize
    Events = count(),
    Requests = dcount(transactionId_s),
    Paths = make_set(requestUri_s, 20)
  by ruleId_s, ruleGroup_s
| order by Events desc

The current AGWFirewallLogs schema records the policy ID, policy scope and transaction ID. The transaction ID joins several rule events produced by one request.

Open the highest-volume group first. Inspect several transactions and compare each rule message with the input the application expects.

Find the field that caused the match

Suppose rule 942100 appears on POST /api/messages. The endpoint accepts customer support text, and messages containing database errors trigger the SQL injection rule.

The general WAF tuning guide explains how to classify the match. The Azure log supplies the rule, field and policy.

Confirm four things before adding an exception:

the same field causes the repeated matches;
the application expects free text in that field;
the requests complete normally in Detection mode;
other fields on the endpoint still need SQL injection inspection.

The development team supplies the application context behind the WAF event. Ask how the field is parsed, validated, stored and rendered. Keep the request examples needed for the investigation, then remove any customer content from the exception record.

Exclude one field from one rule

Azure exclusion lists remove selected request attributes from managed-rule inspection while the WAF evaluates the rest of the request. Application Gateway v2 can exclude request headers, cookies, form fields, JSON entities and query-string arguments. Exclusions can apply globally or to selected managed rules. Microsoft’s exclusion-list guide describes the supported fields and per-rule configuration.

For the message example, select RequestArgValues with the selector message, then limit the exclusion to rule 942100 in the deployed CRS or DRS version. Replay the original request and a second request that places SQL injection text in another field. The support message should pass. The second field should still trigger the rule.

Azure now skips message for rule 942100 and inspects the other request fields.

Per-rule exclusions require the next-generation WAF engine with CRS 3.2, DRS 2.1 or a later ruleset. Microsoft currently recommends DRS 2.2. A global exclusion applies across the web application covered by the policy, so reserve it for a field that has the same meaning everywhere. Microsoft lists these version requirements and exclusion behaviour in the Application Gateway WAF documentation.

Give one site or path its own policy

A policy-level exclusion may cover more applications than the exception requires.

Application Gateway can associate WAF policies globally, with a listener, or with a path-based rule. The most specific policy takes precedence. A listener policy can therefore tune one hostname, while a path policy can tune one URL area. Microsoft documents global, per-site and per-URI policy associations.

Use that layout when message is free text on /api/messages and a structured identifier elsewhere. Put the exclusion in the policy attached to the relevant path. Other listeners and paths keep their existing policy.

Record the association alongside the exception. A future routing change can move traffic under a different policy without changing the exception itself.

Use request exceptions to skip a rule

Azure Application Gateway WAF also has request exceptions. They match a request attribute such as a URI, header or client address, then bypass a selected rule, rule group or ruleset for the matching request.

Use a request exception when one rule cannot inspect any part of a known request safely. The selected rule stops evaluating the matching request, so describe the inspection removed and limit the exception to that rule where possible.

As of July 2026, Application Gateway WAF request exceptions are in preview. They require Application Gateway v2 and the next-generation engine with CRS 3.2, DRS 2.1 or later. Each WAF policy supports up to 60 exceptions, subject to gateway and per-exception limits. Confirm availability, deployment tooling and support expectations before using them in production. Microsoft publishes the current status, supported scopes and limits on the request-exceptions page.

An Allow rule bypasses the managed WAF

When that rule matches, Azure skips the managed DRS, CRS and Bot Protection rulesets for the request. HTTP DDoS rules still run. Microsoft documents the exact consequence of a custom Allow action.

Reserve an Allow rule for a tightly defined, trusted integration. Every matching request bypasses DRS, CRS and Bot Protection, including requests sent after an allowed client is compromised.

Write the trust assumption into the rule description and the exception register. Include the owner, source, listener or path, expiry or review date, and the protections that remain.

Return to Prevention mode

Run the Detection policy until ordinary traffic and important manual flows produce no unexplained matches. Include login, password reset, checkout, file upload, API writes, administration and scheduled integrations.

Then:

save the current policy settings;
change the mode to Prevention while preserving requestBodyCheck;
read the policy back;
replay the requests used during tuning;
monitor Blocked events and 403 responses;
keep a quick rollback procedure ready.

Enable Prevention in stages when separate listeners or applications have different risk. The first application may be clean while a monthly import on the second has never appeared in the logs.

Recheck the same Log Analytics groups after application releases and managed-ruleset upgrades. A new field, content type or route changes what the WAF sees. Record the request, excluded field and owning policy for every exception.

How to Tune AWS WAF with Count, Labels and Rule Priority

2026-07-29T09:15:00+10:00

An AWS managed rule blocks a real customer. You find the request, change the entire rule group to Count and promise to revisit it next week.

Six months later, it is still counting.

AWS WAF lets you change one rule inside a managed rule group to Count, keep the label it adds to matching requests and add a blocking rule immediately after the group. The other managed rules keep their configured actions throughout the investigation.

The general WAF tuning guide explains how to classify the request and document the exception. The AWS configuration begins with the managed rule that matched.

Put the rule in Count

Start with the named rule that caused the false positive.

AWS WAF lets you apply a rule action override to an individual rule inside a managed rule group. Set that rule to Count. The override changes how that rule handles matches in your web ACL; it leaves the managed rule group itself unchanged. AWS describes Count as a non-terminating action, so evaluation continues through the rules that follow. AWS documents individual rule action overrides and the behaviour of Count.

Use the individual override for this job. The older rule-group return override changes the result returned by the group after its internal evaluation. AWS recommends rule action overrides when you want the rules inside the group to count their matches.

Keep the change small:

Record the managed rule group, version and rule name.
Change that rule to Count.
Leave the remaining rules at their current actions.
Reproduce the legitimate request.
Check the Count match and the label added by the managed rule.

AWS Managed Rules add labels to matching requests, and later rules in the same web ACL can inspect those labels. AWS lists labels as the supported way to create exceptions for managed rule groups.

Read the request that matched

The sampled-requests view supports a quick investigation. Full WAF logs provide the history needed to compare matches across users, hosts or endpoints.

With the rule set to Count, look for:

the managed rule name;
its fully qualified label;
host, URI and method;
the matching request component, when AWS supplies it;
the final action taken on the request;
the number of clients and routes producing the same match.

AWS records Count matches from managed rule groups under ruleGroupList[].nonTerminatingMatchingRules. Labels added during evaluation appear in the top-level labels field. AWS populates ruleMatchDetails for SQL injection and cross-site scripting match statements. Other managed detections may provide less detail. The AWS WAF log-field reference describes these fields and their limits.

Treat request data as customer data. Query strings, headers and bodies may contain credentials or personal information. Logging redaction applies to the configured log destination. Web ACL data protection masks matching data before it reaches either logs or sampled requests. Disable sampled requests when they could expose a field that data protection does not cover. AWS explains the distinction in its logging and data-protection guidance.

Group repeated matches by rule name, label, host, path and method. Ask the developer who owns the route what the field means and how the application uses it. Investigate a JSON field containing source code separately from a malformed body that the application accepts.

Block the managed-rule label in the next rule

Suppose a managed SQL injection rule repeatedly matches legitimate messages sent to:

POST api.example.com/v1/messages

The managed rule now runs in Count and adds its documented label. Add a custom rule after the managed rule group. That custom rule should match:

the managed-rule label
AND NOT (
    host = api.example.com
    AND path = /v1/messages
    AND method = POST
)

Give the custom rule a Block action.

Requests that match the managed rule continue to be blocked everywhere except the route you reviewed. On that route, this particular managed-rule match can pass to the rules that follow and eventually to the web ACL's default action.

The order creates the behaviour. AWS WAF evaluates rules from the lowest numeric priority upwards. A later rule can see a label only after the managed rule has added it. Put the managed rule group first and the label-matching rule directly after it. AWS documents both priority order and when labels become available to later rules.

Check the rules that come before the group as well. An earlier Allow or Block action ends evaluation before the managed rule runs. AWS documents Allow and Block as terminating actions, while Count continues to later rules. The rule-action guide explains how actions and priority interact.

The exception covers every field on the exempt route

The label tells you that the managed rule matched. AWS applies the later rule action to that match for the whole request.

On the exempt route, the later Block rule ignores that label regardless of which request field caused the managed-rule match. A different field can trigger the same rule and receive the same exception.

Keep the condition tied to the smallest stable part of the application:

exact host;
exact path or a reviewed path family;
HTTP method;
another server-controlled distinction, when one exists.

A query parameter, header or cookie supplied by the client can narrow which requests match the exception. Confirm the matched request component from the event investigation.

AWS also supports a scope-down statement on a managed rule group. The statement selects which requests enter the group for inspection; every other request bypasses the whole group. Reserve that option for traffic the whole rule group should exclude. AWS describes this evaluation behaviour in its scope-down statement documentation.

Test the complete rule path

Replay this test set:

the original legitimate request on the exempt route;
the same harmless input on another route;
a safe security test that triggers the managed rule on the exempt route;
the same test on another route;
requests that match earlier terminating rules;
normal requests that should pass unchanged.

Then check the WAF logs. Confirm that the managed rule still counts and labels the request, the later rule blocks the label outside the exception, and the final action is the one you intended.

Run the configuration against production traffic in Count while you establish its normal match rate. AWS recommends monitoring metrics, sampled requests and logs, then repeating the tuning cycle until the web ACL behaves as intended. AWS also recommends completing the final stage with production traffic. Its testing guidance lays out that process.

Restore enforcement

The label rule can remain as the enforcement point when the application genuinely needs a route-specific exception. Document:

the managed rule group and version;
the original rule action;
the overridden rule name and label;
the hosts, paths and methods allowed through;
the application owner who confirmed the behaviour;
the requests used to test the change;
the logs and metrics that will reveal a regression;
the next review date.

If the development team removes the input that caused the false positive, remove the custom exception and return the managed rule to its original action. Test that change in Count first, then restore enforcement.

Review the exception after managed rule group updates and application releases. AWS managed groups can use versioned releases, and the label, traffic shape or rule behaviour you investigated may change with the deployed version. AWS publishes the available managed groups, their rules and their labels.

How to Tune Coraza on Caddy

2026-07-29T09:00:00+10:00

Coraza sits inside another server. The connector presents each request to Coraza, Coraza runs the rules and the connector applies the result.

Handler order decides whether Coraza sees the request in time. Body handling decides which fields the rules can inspect. The logging phase decides what you can investigate later.

The example deployment runs Coraza as Caddy middleware with OWASP Core Rule Set. The same CRS tuning principles apply to other Coraza connectors. Their installation, request handling and logging need their own tests.

Put Coraza in the request path

The official Caddy module is compiled into Caddy:

xcaddy build --with github.com/corazawaf/coraza-caddy/v2

The module documentation requires order coraza_waf first in the global options block, which places Coraza at the start of Caddy's HTTP handler order.

{
    order coraza_waf first
}

api.example.com {
    coraza_waf {
        load_owasp_crs
        directives `
            Include @coraza.conf-recommended
            SecRuleEngine DetectionOnly

            SecAuditEngine RelevantOnly
            SecAuditLog /var/log/coraza/audit.log
            SecAuditLogFormat JSON
            SecAuditLogType Serial
            SecAuditLogParts ABFHZ

            Include @crs-setup.conf.example
            Include @owasp_crs/*.conf
        `
    }

    reverse_proxy app:8080
}

The Caddy connector's load_owasp_crs option exposes the embedded Coraza CRS files. The three Include lines then load the recommended Coraza configuration, the CRS setup and the rules.

Coraza also supports CRS files installed on disk. A file-based installation loads the Coraza configuration first, crs-setup.conf second and the CRS rule files last. Choose one source for CRS and record its version so you can compare rule changes during an upgrade.

SecRuleEngine DetectionOnly runs the rules and suppresses disruptive actions such as deny, drop and redirect. Legitimate requests can complete while you collect matches. Coraza sets SecRequestBodyLimitAction to ProcessPartial in this mode. Watch INBOUND_DATA_ERROR because part of an oversized body may remain uninspected.

Test the Caddy configuration before reloading it. Then send a safe request that triggers a known CRS rule through the public listener. Confirm that the Coraza event appears and the request reaches the upstream in DetectionOnly.

Configure the Coraza audit log

The Caddy access log tells you that a request happened. The Coraza audit log tells you which WAF rule matched.

SecAuditEngine RelevantOnly records transactions that produced a warning or error, along with response statuses selected by SecAuditLogRelevantStatus. CRS rules normally carry the auditlog action, so their matches can enter the audit log.

The example uses Coraza's JSON audit format and leaves request-body part C out of SecAuditLogParts. Request bodies often contain passwords, personal information and customer text. Add body logging only for a controlled investigation, then remove it.

The serial audit log in the example is convenient during initial tuning. Coraza warns that serial logging can slow the server because transactions share one file.

Concurrent, HTTPS and syslog outputs suit deployments that need another destination. Send the records to a protected log system with rotation, retention limits and restricted access.

Start each investigation with these fields:

request time and transaction ID;
hostname, method and URL;
rule ID and message;
CRS tags such as attack-sqli or attack-xss;
matched variable name;
matched data;
request and response status.

The variable name identifies the input to investigate. ARGS:message identifies an application field. REQUEST_COOKIES:campaign identifies a cookie.

Handle matched data as customer data. Keep enough to reproduce the result, then retain the rule ID, field name and explanation in the permanent exception record.

Check what Coraza parsed

CRS can inspect only the fields Coraza extracted from the request.

SecRequestBodyAccess On enables body buffering and processing. The selected processor determines which collections phase 2 rules can inspect. URL-encoded forms, multipart forms, JSON and XML produce different variables.

For an unexpected body match, record:

the request Content-Type;
REQBODY_PROCESSOR;
REQBODY_ERROR and REQBODY_ERROR_MSG;
INBOUND_DATA_ERROR;
the matched variable name.

Coraza's current body-processing documentation shows processor selection by content type. The ctl:requestBodyProcessor reference still describes explicit phase 1 selection for JSON and XML. Check REQBODY_PROCESSOR on the Coraza version and connector you run, then select the processor explicitly when the expected processor is missing.

A parsing error deserves its own investigation. Coraza documents the risk plainly: the application may accept a body that Coraza's parser rejected. Compare the application's parser with Coraza using the same bytes. Fix a wrong content type or processor selection before writing a rule exclusion.

Body limits need the same care. SecRequestBodyLimitAction ProcessPartial inspects the bytes that fit within the limit and sets INBOUND_DATA_ERROR. Raise a limit when the application legitimately accepts larger bodies and the deployment can buffer them safely. Keep an alert for the limit condition so partial inspection remains visible.

Load exclusions in the correct order

CRS provides two places for local exclusions.

Use the general WAF tuning guide to classify the match and define the exception. Load that exception according to the CRS rule order below.

A runtime exclusion runs for matching transactions. Load it before CRS so it can change the transaction before the affected rule executes. CRS includes REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example for this purpose.

A configure-time exclusion changes a loaded rule. Load it after CRS so the rule already exists. CRS includes RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example for these changes.

Keep both files outside the CRS distribution. An upgrade can then replace CRS without replacing your application decisions.

The order in a Caddy deployment looks like this:

directives `
    Include @coraza.conf-recommended
    SecRuleEngine DetectionOnly
    Include @crs-setup.conf.example

    Include /etc/coraza/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
    Include @owasp_crs/*.conf
    Include /etc/coraza/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
`

With load_owasp_crs enabled, the Caddy connector merges the embedded CRS filesystem with the operating-system filesystem. The configuration can include embedded @ files and local /etc/coraza exclusion files.

The CRS tuning guide explains the before-and-after placement and the available exclusion actions.

Exclude the field that caused the match

Suppose POST /api/jobs accepts a JSON array. Rule 932125 repeatedly matches legitimate text in each jobDescription field. In this example, the audit log reports variable names such as ARGS:json.0.jobdescription and ARGS:json.1.jobdescription.

Coraza accepts a regular expression for the collection key in ctl:ruleRemoveTargetById:

# REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
# Local rule ID 10010 must be unique in this deployment.
SecRule REQUEST_FILENAME "@streq /api/jobs" \
    "id:10010,phase:1,pass,nolog,t:none,chain"
    SecRule REQUEST_METHOD "@streq POST" \
        "t:none,ctl:ruleRemoveTargetById=932125;ARGS:/^json\.\d+\.jobdescription$/"

This local rule runs only for POST /api/jobs. Rule 932125 continues to inspect every other field in those requests and every field on other routes.

The /pattern/ form is a Coraza feature. The Coraza action reference states that collection-key matching is case-insensitive because Coraza lowercases variable names. Use an exact key such as ARGS:message when the application has one fixed field. A regular expression earns its place when the application produces a documented family of field names.

A field can trigger several rules in one attack class. Coraza also supports ctl:ruleRemoveTargetByTag, for example:

ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:message

The exception removes the named field from every rule carrying the literal attack-sqli tag. Record that scope and confirm that the application protects the field through parameterised queries and suitable validation.

Configure-time exclusions suit fields with the same meaning everywhere:

# RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
SecRuleUpdateTargetById 942100 "!REQUEST_COOKIES:campaign"

This removes one named cookie from rule 942100 throughout the configuration. A route-specific runtime exclusion is the better starting point for an application field.

Check where a chained rule reads the field

Some CRS detections are chained rules. The first rule starts the chain and later rules add conditions.

The CRS tuning documentation states that target exclusions by ID affect only the first rule in a chain. An exclusion will have no effect when the field is inspected by a later chain member. Removing the complete rule may be the available answer.

Find the rule in the CRS version you deployed. Check where the target appears in the chain. Then replay the request against that exact version. The rule source and replay result settle the question.

Replay the request before and after

Save the legitimate request that produced the false positive. Preserve its method, path, query string, content type, important headers and body bytes. Replace credentials and personal data with values that reproduce the same match.

For example:

curl --silent --show-error \
    --dump-header before.headers \
    --output before.body \
    --request POST \
    --header 'Content-Type: application/json' \
    --data-binary @false-positive.json \
    https://api.example.com/api/jobs

Run it once in DetectionOnly before adding the exclusion. Confirm that:

the application returns its normal response;
the audit log contains the expected rule ID;
the log names the expected field;
the request body has no parser or size error.

Add the exclusion, validate the Caddy configuration and reload it. Send the same request bytes again:

curl --silent --show-error \
    --dump-header after.headers \
    --output after.body \
    --request POST \
    --header 'Content-Type: application/json' \
    --data-binary @false-positive.json \
    https://api.example.com/api/jobs

The application response should stay the same. The false-positive match should disappear for the excluded field.

Now send a control request that places a known CRS test value in another field on the same route. Rule 932125 should still inspect that field. Send the original test value to another route as well. The rule should still inspect it there.

Expect these results:

the legitimate request works;
the rule still reads neighbouring fields;
the rule still runs on other routes.

Keep the request fixtures in a protected test repository. Run them after Coraza, CRS, Caddy or application upgrades.

Switch Coraza from DetectionOnly to On

Switch SecRuleEngine to On in a staging environment after the common legitimate flows run without unexplained matches. Repeat the false-positive replay, the neighbouring-field control and the application's critical user journeys.

Enable blocking for a limited production audience or hostname when the deployment allows it. Watch WAF responses, upstream errors and business transactions together. A clean audit log has little value when checkout or login has stopped working.

Document every exception beside the configuration:

who approved it;
the affected hostname, method and route;
the rule ID or tag;
the excluded field;
the request that reproduced the match;
the controls that still inspect or validate the field;
the date and CRS version tested.

How Browsers Decide Whether to Use HTTP/3

2026-07-29T00:00:00+10:00

There is no HTTP/3 switch inside the TLS handshake.

HTTP/1.1 and HTTP/2 both run over TCP. A browser can open TCP port 443, start TLS and use ALPN to choose between http/1.1 and h2. HTTP/3 runs over QUIC, which uses UDP. By the time a normal TLS-over-TCP handshake begins, the browser has already chosen the wrong transport for HTTP/3.

It has to learn that a QUIC endpoint exists first. Then it has to decide whether that information is worth acting on.

Those are separate problems. The discovery mechanisms are covered by standards. The exact decision to wait for DNS, start TCP, race QUIC, abandon a slow attempt or remember a failure is not.

That distinction explains why two browsers can visit the same site from the same network and use different HTTP versions without either one being broken.

Two ways to advertise HTTP/3

The older and more common route is an Alt-Svc response header:

Alt-Svc: h3=":443"; ma=86400

RFC 9114, the HTTP/3 specification, says an origin can advertise an equivalent HTTP/3 endpoint this way. The browser receives the header over an existing HTTP/1.1 or HTTP/2 connection, stores the alternative service and may try QUIC.

The catch is in the sequence. On a first visit, the browser needs an HTTP response before it sees the header. That first connection is already on TCP. A later request can use the cached HTTP/3 alternative.

DNS can provide the information earlier. RFC 9460 defines SVCB and HTTPS resource records. An HTTPS record can advertise ALPN protocols, ports, address hints and alternative endpoints:

example.com. 300 IN HTTPS 1 . alpn="h3,h2"

A browser that receives this record in time can attempt HTTP/3 on the first visit. It does not need to make an HTTP/2 request just to discover that HTTP/3 exists.

Neither advertisement proves that QUIC will work. UDP 443 may be blocked by a firewall, filtered by a corporate network or mishandled somewhere between the user and the edge. The certificate and authority still need to check out. The browser eventually has to test the path.

The standard stops before the interesting bit

RFC 9114 permits a client to try an advertised HTTP/3 service. If QUIC cannot be established, it recommends trying a TCP-based HTTP version. It does not set the browser's race timer or say how long a failed endpoint should remain suspect.

RFC 9460 is similarly careful. It gives the client a set of service endpoints and parameters. It allows TCP and QUIC attempts when the advertised ALPN set supports both. It does not prescribe one universal ordering algorithm.

So there is a standard for saying “HTTP/3 is available here”. There is no standard that says every browser must:

wait the same amount of time for an HTTPS DNS answer;
start QUIC before TCP;
race both immediately;
prefer the same IPv4 or IPv6 endpoint; or
retry a failed QUIC path after the same interval.

Those choices belong to the implementation. They also change.

What Chromium currently does

Chromium source shows why a neat flowchart quickly becomes misleading.

In its established connection path, Chromium can create separate jobs for the ordinary TCP route, a cached Alt-Svc alternative and an HTTP/3 endpoint learned through DNS. The HTTP stream job controller starts the alternative jobs and manages their competition with the main job.

The Alt-Svc information is not rediscovered on every request. Chromium reads it from its stored HTTP server properties, ignores alternatives already marked broken and can create a QUIC attempt from the remaining entry.

That last part matters. If the TCP job succeeds while HTTP/3 fails, Chromium can mark the alternative service as broken. Some failures are treated as specific to the current network and reconsidered after the default network changes. A failed QUIC attempt at the office does not have to poison HTTP/3 after the laptop moves to another network.

DNS discovery is conditional too. The legacy path checks that HTTPS-record ALPN support and QUIC are enabled, that the request is HTTPS, that the connection is direct rather than proxied, and that the DNS alternative is not already marked broken. Merely publishing alpn="h3" does not force Chrome to use it.

Current Chromium also contains a separate Happy Eyeballs v3 connection-pool path. When that path is enabled and eligible, the request leaves the older job-controller sequence. This is a useful warning for anyone interpreting packet captures: “Chrome races these three jobs in this order” may accurately describe one build and be wrong for another.

The durable conclusion is narrower. Chromium gathers candidates, uses remembered success and failure, and is prepared to let TCP and QUIC compete. The timings and plumbing are implementation details.

Firefox makes different choices

Firefox also has explicit HTTP/3 fallback policy rather than a simple protocol preference.

Mozilla's current preferences enable HTTP/3 and fallback to HTTP/2 on error. Its networking code can consume Alt-Svc advertisements and use a DNS HTTPS record as an Alt-Svc-like input.

That DNS path has conditions. In nsHttpChannel, HTTPS-record use depends on such things as the DNS strategy, proxy use, Firefox's encrypted-DNS mode and whether the current network has been judged able to resolve HTTPS records. In some circumstances Firefox waits for the record; in others it proceeds without making the request hostage to that answer.

When Firefox chooses an HTTP/3 endpoint learned from DNS, nsHttpTransaction has a fast-fallback path to a backup connection. After a failed HTTP/3 attempt it can also remove H3-capable SVCB candidates before retrying. If Firefox already has a usable HTTP/3 connection, the connection manager tries to dispatch work there before HTTP/2.

That is a real preference, but it is not a promise that every fresh Firefox connection starts with QUIC. Cached state, proxy configuration, DNS-over-HTTPS status and the current network all affect the choice.

What Apple documents, and what it does not

Apple's HTTP/3 technote recommends an HTTPS DNS record with alpn="h3,h2" for service discovery. It also supports Alt-Svc and explains the practical difference: DNS can make HTTP/3 available on the first transaction, while an Alt-Svc-only client may use HTTP/2 first and apply the remembered advertisement on a later request.

Apple also documents fallback to HTTP/2 or HTTP/1.1 when HTTP/3 is unavailable on the server or network.

That is good deployment guidance. It is not a published Safari endpoint-selection algorithm. WebKit is open source, but much of the Apple platform networking behaviour involved here sits below the rendering engine. We should not turn one Safari test on one release and operating system into a claim about every Apple device.

If Safari on macOS and Safari on iPadOS behave differently in a lab, record the versions, resolver, network and cache state. The difference is evidence worth investigating, not a new browser law.

DNS timing can decide the winner

An HTTPS record is useful only if the browser receives and uses it soon enough.

A, AAAA and HTTPS answers may arrive through different resolver paths and at different times. The browser can wait for more complete endpoint information or begin connecting with the address it already has. Waiting can produce a better candidate set. It can also add visible delay when the missing answer never arrives.

This is one reason browser traces vary with the operating system and DNS configuration. Chrome and Firefox both have internal DNS behaviour, but either can be affected by platform resolver choices, encrypted-DNS settings, proxies, caches and experiment flags.

RFC 10029, DNS Multiple QTYPEs, was published in July 2026 to let a DNS client request additional record types alongside its primary query. A client could ask for A, AAAA and HTTPS information and receive a combined response instead of waiting for three independently timed answers.

That removes one possible source of timing skew. Publication does not mean browsers, resolvers and authoritative servers support it yet. It also cannot make a blocked UDP path work.

Happy Eyeballs is growing beyond IPv4 versus IPv6

Happy Eyeballs originally dealt with a familiar failure: an IPv6 address exists, but the IPv6 path is slow or broken. Rather than make the user wait for a timeout, the client tries another candidate.

The active Happy Eyeballs Version 3 Internet-Draft generalises that work. Its candidate model can account for service endpoints, transport protocols and ALPN, not only IPv6 and IPv4 addresses.

That is the right shape for HTTP/3. A browser may be choosing among:

HTTP/3 over QUIC to an IPv6 address;
HTTP/3 over QUIC to an IPv4 address;
HTTP/2 over TLS and TCP to either address; and
endpoints with different priorities or ports from an HTTPS record.

Version 3 is still an Internet-Draft, not a finished standard. Chromium having a feature called Happy Eyeballs v3 does not mean its current behaviour is the final IETF algorithm, and it does not mean other browsers use the same timers.

What operators should do

Advertise HTTP/3 with both DNS HTTPS records and Alt-Svc.

The HTTPS record gives capable clients a chance to use QUIC on the first connection. Alt-Svc reaches clients that learn alternatives through HTTP responses and provides a second discovery path. Keep HTTP/2 working on TCP 443 because HTTP/3 is an additional path, not a safe replacement for fallback.

Then measure the versions separately. At the edge, record the negotiated HTTP version, QUIC handshake success, fallback rate, network and browser family. Test from clean profiles as well as warm ones: cached Alt-Svc and remembered QUIC failures can completely change the result.

When a test surprises you, capture more than the browser name. Record:

browser and operating-system versions;
whether the profile was new or had visited before;
the A, AAAA and HTTPS answers actually returned;
Alt-Svc value and cache lifetime;
whether UDP 443 worked on that network; and
whether a proxy, VPN or encrypted-DNS mode was active.

Cloud Fellows has published its protocol-negotiation and DNS HTTPS versus Alt-Svc test setup. It is useful for reproducing these cases and comparing results across browser versions, operating systems and resolver configurations.

HTTP/3 discovery has standards. Browser connection strategy is still a moving piece of software. For operators, the sensible response is not to predict one universal race. Advertise both paths, preserve fallback and measure what clients actually do.

How to Protect APIs From Unwanted Automation

2026-07-29T00:00:00+10:00

APIs are built for automation. That makes “block the bots” a fairly useless brief.

The same inventory endpoint might serve a mobile app, a partner feed and a scraper. All three clients can send valid requests. All three can hold valid credentials. The real question is whether that client is using that route in a way the business intended.

That sounds obvious. In practice, many API controls are still applied across a hostname or an IP range, with little regard for what the route actually does.

Begin with the route that can hurt you

Pick a sensitive operation: login, password reset, account lookup, checkout, reservation, coupon redemption or a costly GraphQL query. Ask its owner three things:

Who is meant to call it?
What does normal use look like?
What should happen when use falls outside that pattern?

The answer will not always be “block”. A public catalogue may tolerate a fair amount of crawling. A reservation endpoint probably should not let one client hold the entire available inventory. A partner export needs a machine-readable error and a phone call to the partner, not a browser challenge.

OWASP describes this problem as API6:2023 Unrestricted Access to Sensitive Business Flows. It includes automated purchasing, reservation abuse and referral fraud: ordinary application functions used for an unwanted purpose. The OWASP Automated Threats project covers the familiar variants, including credential stuffing, scraping, scalping and inventory denial.

Security can help enforce the decision, but it cannot invent the decision. The product or service owner has to say which use is legitimate and what the business is prepared to do about the rest.

Find the API you actually have

Policies written against an architecture diagram miss old mobile versions, forgotten staging hosts and endpoints that never made it into the OpenAPI file. Those routes still reach real systems.

API9:2023 Improper Inventory Management calls for an inventory of hosts, environments, versions, endpoints and data flows. This is not paperwork for its own sake. You need a real route and method before you can attach a useful control to it.

Peakhour API Security discovers REST, GraphQL and WebSocket routes, including shadow and legacy endpoints. Where an OpenAPI or Swagger contract exists, Peakhour can show requests that have drifted from it.

Schema is useful, but it is not intent. A perfectly valid checkout can still be abusive. Schema tells us what arrived and where; the route policy tells us whether to allow it.

Do not make JavaScript a requirement

A partner integration or machine-to-machine service does not need JavaScript to be protected. Peakhour can assess direct API traffic using route, method, schema result, authentication outcome, headers, protocol behaviour, network path, response code and request cadence.

JavaScript is useful when the API call belongs to a browser-backed journey. It can add browser and device consistency signals, or support a challenge before a sensitive account action. That is optional evidence. A direct API client does not need JavaScript, and its absence is not evidence of abuse.

This has an operational consequence: choose an action the intended client can complete. A customer resetting a password in a browser may be able to pass a step-up check. A partner batch cannot.

Count something that survives an IP change

An IP limit is easy to understand and sometimes it is enough. It is a poor fit for distributed credential testing, residential proxy traffic and clients behind carrier-grade NAT.

API4:2023 Unrestricted Resource Consumption recommends limits suited to the operation. Password recovery, one-time-code validation, GraphQL batching and large responses have different costs and should not share one threshold.

Peakhour's Advanced Rate Limiting can count using documented inputs including path, headers, IP, ASN, country, TLS fingerprint, response code and bot-verified status. Each rule has a threshold, interval and action, with counters showing what it allowed, blocked or saw cross the threshold.

The important part is being able to explain the counter. “One hundred requests per minute” is not much of a policy until we know the route, which clients are grouped together, and why one hundred is the point at which use becomes harmful.

Application context can improve that policy. An account, tenant, session or API credential may be a better unit than a network address, provided the integration supplies it safely. Do not casually copy credentials into logs or rule labels.

Treat fingerprints and proxy detection as evidence

Attackers rotate addresses because IP-only controls are easy to distribute around. Legitimate traffic also shares addresses in offices, hotels, universities and mobile carrier networks.

TLS behaviour, HTTP/2 settings, header shape and browser consistency can group requests into a client cohort even as the source IP changes. That can reveal a tool family or a recurring campaign. It does not reveal the person operating it. Fingerprints collide, change and can be copied. They are evidence, not identity.

The same caution applies to residential proxy detection. A proxy signal can justify closer inspection or a tighter limit on a sensitive route. It is not a sound reason to block every request that looks residential.

Expect the first policy to be wrong

A mobile release changes its request shape. A partner runs a larger batch. A sale changes normal checkout traffic. The attacker slows down and moves from login to token refresh.

We start sensitive API controls in monitoring unless the active harm demands an immediate block. Keep the route, evidence, action and response outcome together. Log forwarding sends that record to the customer's existing SIEM or observability platform.

Before tightening a policy, we want two answers:

What unwanted activity did it reduce?
Which intended clients did it inconvenience?

The Gumtree case study is not an API-only case study. It is relevant because it records how this tuning works in production. Gumtree and Peakhour deployed progressively and adjusted controls against live traffic. Gumtree reported a 3.3x cleaner origin mix and an 80% reduction in Gumtree's internal fraud score. Those figures belong to the broader bot-management deployment, not to an isolated API feature.

One request should produce one decision

An automated campaign does not respect product categories. The same traffic can use valid API calls, stolen credentials, residential proxies and changing client fingerprints while also carrying payloads that need WAF inspection.

Peakhour puts API protection, managed WAF/WAAP, bot management, advanced rate limiting, DDoS protection, anomaly detection and origin protection in the same request path. It can run on Peakhour Edge or alongside an existing CDN or edge provider. Operators get one decision to review, with the evidence that produced it, rather than a pile of unrelated scores.

API Bot Protection shows how we apply that model to login, token, checkout and account routes.

How to Tune Your WAF Without Turning It Off

2026-07-28T10:30:00+10:00

The OWASP Core Rule Set has never seen your application.

Generic patterns let it recognise common signs of SQL injection, cross-site scripting and protocol attacks. Tuning teaches it that your application stores a search expression in JSON, accepts links in a message field or receives an analytics cookie full of punctuation.

So a new deployment will be noisy.

Faced with that noise, teams often leave the WAF in log-only mode forever or disable each rule that causes a complaint. Teams need a repeatable route from noisy alerts to safe blocking.

The work is repetitive and fairly unglamorous: observe real traffic, group related matches, understand the application field involved, write the narrowest safe exception and repeat until legitimate traffic no longer triggers unexplained alerts.

Start in detection-only mode

Introduce the full OWASP CRS to an existing production application in detection-only mode.

On ModSecurity or Coraza, set SecRuleEngine DetectionOnly. The engine records what the rules would have denied, dropped or redirected while allowing the requests through.

Both engines support this rollout. The ModSecurity FAQ recommends detection-only mode for a new ruleset, and Coraza implements the same setting.

Run it long enough to see the application's real shape. Allow at least a full week, and often one to two weeks, so the sample includes business days, a weekend and any less frequent jobs, imports or campaigns.

Exercise authenticated actions, checkout, password reset, messaging, file upload, API writes and administrative tools manually because ordinary browsing may never reach them.

Detection mode records rule matches while passing every request through, including attacks. Decide in advance what needs to be true before you enable blocking.

What changes between WAF products

The examples below use SecLang and OWASP CRS because they expose the rule ID, attack class and request field that caused a match. Managed WAFs record much the same information under different names, with varying precision for exceptions.

Coraza also runs CRS 4. It is a Go implementation of SecLang, and the CRS project recommends it for new CRS 4 deployments. The Coraza tuning guide covers its audit logging, connectors and runtime exclusions in more detail.

Body processors and chained rules can behave differently between engines and web-server connectors. Replay the requests that caused the false positive through the engine and connector that handle production traffic.

Tuning job	SecLang / CRS	Managed WAF examples
Observe without blocking	`SecRuleEngine DetectionOnly`	Azure Detection mode, AWS rule-action override to Count, Google Cloud Armor preview
Identify the detection	numeric rule ID and message	managed rule ID or name
Identify the class	CRS tag such as `attack-sqli`	rule group, category or emitted label
Identify the input	`REQUEST_COOKIES:name`, `ARGS:field`, header or body target	matched request component or exclusion selector
Narrow the exception	target removal by ID or tag, optionally limited to a route	field exclusion, per-rule exception, label-based follow-on rule or rule skip limited by request conditions

The last row is where the products differ most. ModSecurity and Coraza can stop one rule from inspecting one field on one route. Some managed WAFs can only skip the whole rule for requests matching that route. If that is the smallest exception available, write down exactly what the WAF will stop inspecting and decide whether the route is safe without that rule.

Group alerts before reviewing them

Reviewing WAF alerts one at a time hides repeated false positives.

The same harmless field may trigger the same rule across thousands of requests. Conversely, two alerts with the same rule ID may come from completely different application behaviours and need different decisions.

Group events using at least:

hostname and URL;
HTTP method;
CRS rule ID;
rule class or attack tag, such as attack-sqli or attack-xss;
matched-data variable, including its collection and exact name;
WAF action and response status;
event count, distinct clients and spread over time.

For example, REQUEST_COOKIES:analytics_id is much more useful than “SQL injection rule fired”. So is ARGS:message on POST /api/messages.

The rule ID tells you which detection fired. The attack class tells you which protection an exception would weaken. The matched variable identifies the request field that caused it. The URL and method show where the application uses that field.

Keep a few examples of the matched values long enough to investigate them, but handle them carefully. Request fields can contain credentials, personal information and customer content. The exception record usually needs the variable name and an explanation, not a permanent copy of the raw value.

Expect false positives in a few places

A few kinds of input generate most legitimate matches.

Request cookies

Marketing, attribution, experimentation and client-state cookies often contain encoded or structured values. A generic SQLi, PHP or local-file-inclusion rule may find a suspicious fragment even though the application never treats that cookie as executable input.

Keep inspection active for the REQUEST_COOKIES collection and exclude only the cookie that caused the false positive.

Identify the cookie name, the rules or attack classes it triggers, the routes where it appears, how often it occurs and whether those requests complete normally. If REQUEST_COOKIES:analytics_id repeatedly triggers the same attack class for legitimate requests, consider an exception for that cookie alone.

Cookie names need separate treatment. A rule matching REQUEST_COOKIES_NAMES inspects the names. Capture the exact name safely before writing the exclusion.

Unparsed or malformed request bodies

Parser errors deserve their own investigation.

When a selected body processor cannot parse a body, ModSecurity and Coraza set REQBODY_ERROR. Record the Content-Type and observed REQBODY_PROCESSOR because JSON and XML processor selection varies by engine, connector and version. Confirm that a processor ran before relying on the error flag.

A body that exceeds the configured inspection limit is a different case. It sets INBOUND_DATA_ERROR and may be inspected only partially. In either case, part of the body may go uninspected, and an attacker can deliberately probe that behaviour.

Ask the developer who owns the endpoint what it is meant to accept. Fix incorrect content types and body-processor configuration, reproduce the request, then check whether the application and WAF parse it the same way.

Keep request-body inspection active for the application. Limit any parser exception to the host, URL, method and body behaviour you investigated.

Free-text fields

Messages, descriptions, comments, support tickets and search boxes are expected to contain language that resembles attack syntax. A customer can discuss SQL without attempting SQL injection. A marketplace listing can contain shell characters. A support message can include a URL.

Exclude the named field on the affected route and keep inspection active for the rest of the request body.

For example, the SecLang rule below removes ARGS:message from every rule tagged attack-sqli on the messaging endpoint. That is appropriate only if you have decided that SQLi inspection is too noisy for this field across the whole class. Every other argument still receives SQLi inspection, and scam, malicious-link or other attack classes can continue inspecting the message.

Bring in the developer who owns the endpoint. They can confirm whether the field is genuinely free text, where it is stored or rendered, what server-side validation exists and which security checks still need to see it.

Application-specific structured fields

Some applications accept query languages, filters, templates, product metadata or nested JSON that naturally looks like code. The syntax may be legitimate, but these fields still deserve careful review before they are excluded.

Confirm the schema and business use before creating an exception. Check that MATCHED_VAR_NAME identifies one field, then use that exact named target. Nested JSON naming varies between engines and integrations. Keep SQLi inspection active for the rest of the API when one structured field needs an exception.

Make the smallest exception that works

Work down this list and stop as soon as the known false positive is fixed:

host, exact URL, method, rule ID or attack class, and exact named variable;
host, reviewed URL family, method, class, and named variable;
host, exact URL and rule ID;
host, rule ID;
global named-variable exclusion.

Start with the first option. Move further down only when the logs and the application design justify a wider exception.

A global exception can make sense for a named cookie or header that has no security meaning anywhere in the application. Before adding one, make sure the false positive appears across several routes and clients, and that those requests complete normally. Ask the development team to confirm that no backend interprets the field.

Even then, remove only that named field from the relevant rule or attack class. An exception for REQUEST_COOKIES:analytics_id removes one known input from SQLi inspection. An exception for the whole cookie collection removes every cookie.

Reserve global exceptions for logs that identify the matched field. Unknown body fields, unresolved cookie names and parser failures need manual investigation.

Keep your exceptions outside CRS

Put application-specific exceptions in local configuration and leave the Core Rule Set files unchanged. This keeps CRS upgrades separate from changes made for your application.

To stop one rule inspecting a named field everywhere, ModSecurity and Coraza support:

SecRuleUpdateTargetById 942100 "!REQUEST_COOKIES:analytics_id"

Load this directive after the CRS rules because the engine must load a rule before updating it.

For a route-specific exception, use a runtime control before the CRS rule executes:

# Load before CRS, normally from REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.
# Use this rule only for api.example.com.
# Confirm that local rule ID 10001 is unused.
SecRule REQUEST_FILENAME "@streq /api/messages" \
    "id:10001,phase:1,pass,nolog,t:none,chain"
    SecRule REQUEST_METHOD "@streq POST" \
        "t:none,ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:message"

With this exception, SQLi rules stop reading ARGS:message only on POST /api/messages. They still inspect other fields and routes, while other attack classes can continue inspecting the message.

The CRS false-positive tuning guide documents configure-time and runtime exclusions by rule ID or tag. The attack-sqli selector above is a literal tag that works with both ModSecurity and Coraza. ModSecurity runtime target selectors accept literal collection keys. Coraza also accepts regular expressions for collection keys, using /pattern/ syntax.

A target exclusion may affect only the first rule in a chained CRS detection. Test the exact rules and requests on your deployed engine before relying on the exception.

Use rule IDs or exact attack-class tags. Rule messages can change and may contain request data.

Managed WAFs expose different controls

Each managed provider expresses the exception differently.

AWS Managed Rules can emit a label while an offending rule runs in Count mode. A later custom rule can block that label everywhere except the route that produced the false positive. The exception affects enforcement for the whole managed rule on that route. How to Tune AWS WAF follows that evaluation path from the first counted request to restored blocking.

Azure Application Gateway WAF can exclude a named cookie, header or argument from a particular managed rule. Its request exceptions can instead skip a selected rule for matching traffic, and that feature is currently in preview. A custom Allow rule bypasses the managed CRS, DRS and bot rules for the request. How to Tune Azure Application Gateway WAF shows how to choose among those controls.

Cloudflare exceptions skip a selected managed rule for the whole matching request. Security Events may show rule 949110 as the blocking event because it checks the final anomaly score; Additional logs identify the rules that added that score. How to Tune Cloudflare WAF covers that investigation and the ordering of account-level and zone-level exceptions.

Google Cloud Armor can exclude a named request field from a versioned OWASP signature. Route-specific tuning also depends on the security-policy expression and rule priority, because a general WAF rule may inspect the same request later. How to Tune Google Cloud Armor covers preview, signature selection and field exclusions.

F5 BIG-IP Advanced WAF separates policy enforcement mode, violation actions and signature or entity staging. Its overrides can target a URL parameter, cookie, content profile, URL or the whole policy. How to Tune F5 BIG-IP Advanced WAF follows those controls from Transparent mode to tested blocking.

Provider interfaces, ruleset versions and preview features change. Record the rule name or versioned signature, the field or request being exempted and what the WAF will still inspect. Test the requests that led to the exception before enabling it.

Iterate until the false positives are gone

After adding an exception, group the alerts again. Check whether that false-positive pattern disappeared, whether a related rule started matching the same field and whether another route was affected. Look for legitimate flows that the first observation window missed.

Repeat the cycle:

collect detection-only traffic that covers normal application use;
group by route, method, rule ID, rule class and named variable;
classify abusive traffic separately from legitimate matches;
create or narrow exceptions;
rerun automated and manual application flows;
collect another window.

Aim for zero known false positives in the traffic you observed and the critical flows you tested. A new endpoint, cookie, client or release can produce fresh false positives tomorrow.

Use a higher anomaly threshold only during tuning because it can allow attacks that the normal threshold would have blocked. Write an exception for the rule and field causing the false positive, then return to the intended threshold.

Document every exception

Give every exception an owner, a reason and a review date.

Record:

hostname, URL or URL family, and HTTP method;
CRS version, rule IDs and attack-class tags;
matched collection and exact variable name;
sample event IDs and observation window;
why the traffic is legitimate;
which customer or application flow depends on it;
what protection is removed and what remains active;
developer and security approvers;
date introduced and next review date;
the release, incident or ticket associated with the change.

Keep the exception under version control. Give it a description that another engineer can understand without finding the original chat thread. Review it after CRS upgrades because rule IDs, paranoia levels and rule behaviour can change. The CRS project specifically recommends returning to detection mode long enough to exercise normal traffic after a major migration.

Remove an exception when the application no longer needs it. If the application changes its cookie, parser or validation, restore inspection.

Decide what a WAF hit should do

Security and application owners must decide which matches to log, block, rate limit, challenge or review.

With CRS anomaly scoring, an individual rule normally adds to a transaction score. The WAF blocks when the inbound score crosses the configured threshold, allowing several weak signals to add up before a customer is blocked.

Decide which outcomes you need:

Log: useful during tuning and for low-confidence signals.
Block: appropriate when several signals point to an attack and the affected flow has been tested.
Rate limit: useful for repeated behaviour across several requests.
Challenge or step up: where the product supports it, useful for browser and account flows where a hard block would be unnecessarily disruptive.
Review: appropriate for high-value actions where context matters more than a generic signature.

Respond to a single SQLi alert at the request level. Shared networks, mobile carriers and proxies make IP identity unreliable. Repeated WAF hits on the same route can inform a rate limit, but the limit should use the best available client, session or account key and have a clear window.

Track WAF blocks and rate limits separately. A ModSecurity or Coraza block commonly returns 403; a rate limit commonly returns 429. If the logs say the WAF blocked a request but the origin returned success, find out why before trusting the enforcement reports.

Recheck the WAF after application releases

A release may add an endpoint, rename a field, introduce GraphQL, change JSON shape, add a marketing cookie or move validation between services. Any of those changes can make an old exception too broad or cause a new legitimate field to trigger CRS.

Include the development team in the release process:

list new or changed public routes and methods;
identify free-text, upload and structured fields;
run staging traffic through the same CRS configuration;
test authenticated and high-value journeys;
watch the grouped detections during the production rollout;
give new or substantially changed routes an observation period before enforcing new rules on them;
review whether old exceptions can be removed.

For major CRS upgrades, treat the ruleset itself as a release. A ruleset upgrade can change rule IDs and anomaly-score behaviour while the application stays the same.

Know when tuning is complete

A traditional WAF is ready to enforce when:

normal production traffic, including the less common application flows, has been reviewed;
critical application flows have been tested with developers;
every high-volume legitimate match has a documented, narrow exception;
parser failures and unresolved matched variables have named owners and specific resolutions;
WAF blocks produce the expected response;
rate limiting is handled separately from payload detection;
exceptions are versioned, approved and reviewable;
new rules and releases can be observed before they start blocking.

Once those checks pass, enable blocking in stages and keep watching the same groups of alerts. Revisit the exceptions whenever the application or ruleset changes.

For the broader decision about where a WAF helps and where it does not, see When and Why to Use a WAF. You can also read about Peakhour's web application firewall.

When and Why to Use a WAF: A Guide for WAF Sceptics

2026-07-28T10:00:00+10:00

There are two popular opinions about web application firewalls.

The first is that every public application needs one. Turn it on, enable the managed rules and enjoy protection from the OWASP Top 10, zero-days, bots and DDoS attacks.

The second is that WAFs are expensive regex machines. They block customers, miss clever attacks and give management a green tick while the application remains vulnerable.

The second group has better jokes. Neither group has the whole answer.

A WAF is useful when it is given a job it can actually perform. It is disappointing when it is expected to understand an application better than the people who built it.

The practical question is not “do WAFs work?” It is: which risks can this WAF reduce, what will it never understand, and who will operate it when the application changes?

What a WAF can see

A traditional WAF sits in the HTTP request path. It inspects requests and applies managed or custom rules before passing allowed traffic to the application.

That position gives it a useful but limited view.

It can see paths, methods, headers, cookies, query strings and supported request bodies. Depending on the product, it may also have access to IP reputation, network characteristics, bot signals, rate history and API schemas.

It cannot naturally see the full business meaning of the request.

The WAF may know that a customer requested /api/invoices/123. The application knows whether that customer owns invoice 123. The WAF may see 200 valid checkout requests. The application knows whether they represent a wholesaler, a scalper or a broken integration.

That boundary explains both the value and the frustration.

The criticism is mostly fair

WAF sceptics are right about several things.

A determined attacker can bypass generic detection. Differences in encoding and HTTP parsing can cause a WAF and an application to interpret the same request differently. A 2024 study found 311 protocol-level evasion cases across 14 WAFs and 20 web frameworks.

False positives are real too. Legitimate HTML, JSON, support messages or product descriptions may resemble an attack signature. Microsoft recommends introducing a WAF in detection mode, reviewing logs and tuning it before blocking. It says this process may take several weeks.

A WAF also cannot fix insecure application logic. It cannot repair broken object-level authorisation, make password recovery safe or decide whether a valid-looking transaction is fraudulent. Those controls belong in the application.

And, yes, putting anything inline creates another dependency. A poor rule can block real customers. A provider can have an outage. A self-hosted appliance can fail open or fail closed.

These are reasons to be precise about the job. They are not reasons to send every internet request directly to the origin.

Buying time during a patch window

The best reason to have a WAF is rarely mentioned on the product page. It buys time.

When a serious vulnerability appears, the correct response is to fix the affected software. But finding every instance, testing the patch and deploying it safely may take hours or days. Third-party and legacy applications can take longer.

A virtual patch can narrow that exposure window. A custom rule may block the vulnerable path, reject a malicious parameter or detect the request pattern associated with the exploit while the real patch is prepared.

OWASP's virtual patching guidance is clear about the boundary: correcting the source is the preferred remediation. The WAF rule is a compensating control, not permission to leave the vulnerability in place.

That still makes it valuable. During an incident, ten minutes and two days are very different amounts of exposure.

Stopping expensive requests earlier

Applications are expensive places to reject bad traffic.

By the time a request reaches application code it may have consumed a connection, invoked authentication, queried a database, called another API or triggered a paid service. A request does not need to contain an obvious exploit to create cost. It may simply repeat an expensive operation far more often than a legitimate user would.

An edge control can reject common exploit traffic and excessive requests before that work happens.

This is especially useful for login, search, registration, password reset, checkout and expensive API routes. Rate limits and bot controls can respond differently based on route, session, account outcome and other available evidence instead of treating every request from an IP address as the same actor.

NIST recommends applying general WAF, bot and denial-of-service controls early in the API serving stack to protect upstream systems from malicious payloads and unrestricted resource consumption. It also treats those as separate capabilities.

That distinction matters. A classic WAF does not automatically provide sophisticated bot management or network-scale DDoS protection. A broader WAAP service may bundle them, but buyers should check the controls rather than trust the acronym.

A control you can reach during an incident

Security incidents create awkward gaps between knowing there is a problem and having the final fix ready.

Perhaps one endpoint is being abused. A new exploit is spreading. Login failures are climbing. A scraper is rotating through residential proxies. An old hostname that should have disappeared is suddenly receiving traffic.

A centrally managed WAF gives the operations team somewhere to make a narrow, reversible change without waiting for several application releases. They can restrict a route, add a virtual patch, change a rate limit, challenge suspicious traffic or collect more detailed events while the investigation continues.

That operational separation is valuable. The application team can work on the root cause while the security or operations team reduces immediate exposure.

It also needs discipline. Emergency rules require owners and expiry dates. A temporary exclusion should not survive for years. Changes should be observed before blocking where the situation allows it.

Evidence before the origin

A WAF is often discussed only as a blocking device. Its position in the request path can be just as useful for understanding what is happening.

Good events can show which route was targeted, which rule matched, what action was taken and whether the request reached the origin. Rate, bot and API signals can add context. Combined with application logs, this helps teams distinguish an attack from a customer problem, a broken integration or a badly tuned rule.

The same visibility can expose weaknesses in the deployment itself:

a forgotten API version receiving traffic;
a hostname missing the expected policy;
an origin that is still publicly reachable;
an endpoint whose cost makes it an easy denial-of-service target;
an exclusion that is much broader than anyone remembered.

This does not require blocking on day one. Observe mode can create value before the team is confident enough to enforce a decision.

When the case for a WAF is strong

A WAF is usually worth serious consideration when the application has several of these characteristics:

customer accounts, payments or personal information;
public APIs or expensive dynamic routes;
third-party, legacy or slow-to-patch software;
regular scanning, credential stuffing, scraping or automated abuse;
multiple applications that need consistent emergency controls;
compliance requirements for runtime web protection;
an operations team able to tune rules and investigate events.

PCI DSS provides one concrete example. Since 31 March 2025, Requirement 6.4.2 requires an automated technical solution in front of applicable public-facing web applications to continually detect and prevent web attacks. The PCI Security Standards Council describes the requirement without requiring a particular product called a WAF.

Compliance is a legitimate reason to deploy the control. It is not evidence that the deployment works.

When the case is weak

Not every website needs a large WAAP contract.

A genuinely static, low-value site with no accounts, API or meaningful dynamic input presents a smaller application attack surface. Basic CDN protection, origin restriction, good patching and sensible security headers may be enough.

The case is also weak when nobody will own the WAF. An ignored ruleset eventually becomes noisy, stale or full of broad exclusions. A dashboard that nobody checks is not defence in depth.

Be cautious when the proposed product does not match the actual problem. A signature WAF is not the complete answer to sophisticated bots. An on-premises appliance cannot absorb a volumetric attack larger than its internet connection. Edge rules cannot repair business logic. A provider's “AI-powered” label does not establish an acceptable false-positive rate.

Sometimes the right answer is a smaller control. Sometimes it is a different control. The point is to buy against the risk rather than the category name.

How not to become the WAF horror story

Most bad WAF experiences begin with the same mistake: enabling everything and immediately blocking production traffic.

A safer deployment looks less exciting:

Define the job. Decide which applications, routes and abuse cases the WAF is expected to cover.
Put all relevant traffic through it and restrict direct access to the origin.
Start managed rules and new controls in observe or count mode.
Review real production-shaped traffic and tune false positives narrowly.
Test login, checkout, uploads, APIs and other important customer journeys before enforcement.
Give every custom rule and virtual patch an owner, reason and review date.
Monitor allowed as well as blocked traffic so false negatives do not disappear from view.
Keep application-level authorisation, validation and rate controls in place.
Test what happens when the WAF, agent or provider is unavailable.

That is the difference between owning a control and merely paying for one.

Where this leaves us

A WAF is neither useless nor sufficient.

It cannot understand every valid-looking abuse, prevent every bypass or rescue an application that ignores secure design. It introduces cost, tuning and another inline dependency.

It can still stop a great deal of cheap hostile traffic, buy time during a vulnerability, prevent excessive work from reaching the origin, give operators a fast response point and leave evidence that helps explain an incident.

Our two companion articles make each side of the case directly: Everyone Says a WAF Is Useless. Are They Right? and Your Application Needs a WAF. Just Not for the Reason You Think.

The conclusion is less catchy than either headline. Use a web application firewall when the application has something worth protecting, the WAF has a defined job and someone is responsible for operating it. Then keep fixing the code behind it.

Your Application Needs a WAF. Just Not for the Reason You Think

2026-07-28T09:30:00+10:00

A web application firewall will not make bad code good.

It will not repair broken access control. It will not redesign an unsafe checkout. It cannot decide whether a customer should be allowed to see a particular invoice, transfer money from an account or buy the last 200 tickets to a concert.

If your public application has accounts, valuable APIs or expensive dynamic routes, you probably still need one.

The case has nothing to do with an invisible shield or a promise to “solve the OWASP Top 10”. Public applications meet hostile traffic every day, software is imperfect and fixing the right thing often takes longer than attacking it.

That is what a WAF is for.

The internet does not wait for your next release

Every public application receives traffic it did not ask for.

Some of it is harmless background noise: crawlers looking for software that is not installed, scripts requesting old WordPress paths, scanners testing yesterday's vulnerability against every address they can find.

Some of it is aimed directly at the application: SQL injection attempts, malicious uploads, path traversal, unusual encodings and requests crafted to trigger a known vulnerability.

The application can reject those requests itself. Ideally, it will. But allowing every request to reach application code, authentication services, databases and third-party APIs is an expensive way to discover that something is hostile.

A WAF creates an earlier decision point. It can discard common exploit traffic before the request reaches the part of the system that holds customer data or performs expensive work.

That does not make the application secure. It means the application no longer has to face every cheap attack on its own.

Patches take time. WAF rules take less

The clearest reason to run a WAF is virtual patching.

Suppose a serious vulnerability appears in a framework, CMS plugin or third-party product. The responsible answer is to patch it. But first the team has to identify every affected system, test the update, work around compatibility problems and arrange a safe deployment.

The attacker does not have to do any of that.

A targeted WAF rule can reduce the exposure while the real patch is prepared. It may block a particular path, parameter, payload or request shape associated with the exploit. It is not the final repair, but it can turn an open window into a much narrower one.

OWASP's virtual patching guidance is refreshingly practical about this. Fixing the source is the number-one technical remediation. A virtual patch is useful when that fix cannot happen immediately. The two controls are complementary, not rivals.

This matters most for legacy applications, third-party software and systems with slow release cycles. Those are exactly the places where “just fix the code” can be correct advice and an inadequate incident response.

Your application should not absorb unlimited work

Not every damaging request contains an obvious attack string.

A search request may be perfectly valid but expensive. A login attempt may fail normally while being one of a million credential-stuffing attempts. A scraper may request public pages exactly as a browser would, just much faster. A customer-facing API may trigger email, SMS, payment or database costs every time it is called.

This is where a modern WAAP service goes beyond a traditional signature WAF. Rate limiting, bot management and application-layer DDoS controls can make decisions based on the route, request rate, account outcome, browser or network evidence, and the work the origin is being asked to perform.

NIST recommends placing general WAF, bot and denial-of-service controls early in the API serving stack so malicious payloads and unrestricted resource consumption do not exhaust upstream systems. Importantly, NIST treats these as related but separate capabilities. Buying something called a WAF does not automatically mean all three are present.

Reject bad or excessive work before it becomes expensive work.

Put the checks in different places

Good application security is built in layers because each layer knows something different.

The application knows who owns an object, whether an account may perform an action and what a valid transaction looks like. It should remain authoritative for those decisions.

The edge sees different evidence. It can compare traffic across routes and hosts, recognise widespread exploit patterns, apply an emergency rule across several applications and notice that one client is creating an unusual amount of work before the request reaches the origin.

Neither view is complete.

A WAF is valuable because it is independent of the code it protects. If an application developer makes a mistake, the WAF may still reject the exploit. If a WAF misses a clever request, the application should still validate it. One control can fail without immediately making the failure fatal.

If either layer makes a mistake, the other still gets a chance to respond. That is the useful part of defence in depth.

It gives you somewhere to respond

During an incident, speed matters.

Teams often know enough to reduce the risk before they know enough to ship the final fix. They may need to restrict a vulnerable endpoint, block an exploit pattern, lower a rate limit, challenge suspicious login traffic or temporarily exclude a region where an attack is concentrated.

Doing that through application releases can be slow, especially when several services are affected. A centrally managed WAF gives operators somewhere to make a narrow, reversible change while the application teams investigate.

The words “narrow” and “reversible” matter. Emergency blocks need owners and expiry dates. Rules should be tested in observe mode where time permits. Broad exclusions created during the incident should not quietly become permanent architecture.

The WAF is useful here because it is an operational control, not because it knows more about the application than its developers do.

It leaves evidence at the front door

Prevention gets most of the attention, but visibility is one of the better reasons to have a WAF.

When an application behaves strangely, the team needs to know what arrived before the failure. Which routes were targeted? Were requests blocked or allowed? Did the traffic share a network, client pattern or payload? Was a rate limit crossed? Did the attacker reach the origin directly?

Useful WAF events can answer part of that story. Combined with origin and application logs, they help distinguish a real attack from a broken integration, a customer mistake or a badly tuned rule.

They can also reveal traffic that nobody knew was public: an old API version, forgotten hostname, administrative route or direct-origin path.

Logs are not automatically useful. A million unexplained rule matches can be worse than a smaller set of events tied to route, action and outcome. But without evidence at the entry point, incident response starts with a large blind spot.

Compliance is a reason, but not the best one

For organisations handling payment-card data, a runtime application control may not be optional. Since 31 March 2025, PCI DSS Requirement 6.4.2 requires an automated technical solution in front of applicable public-facing web applications to continually detect and prevent web attacks.

The PCI Security Standards Council describes the requirement without mandating a particular product called a WAF.

That distinction matters. Compliance can justify the control, but it does not prove the control is effective. A WAF in log-only mode with nobody reading the alerts is not much of a defence. Neither is one with a public origin that attackers can reach directly.

Passing an audit is a business requirement. Blocking useful attacks without blocking customers is the security requirement.

A WAF needs to be operated, not merely purchased

The case for a WAF comes with a condition: somebody has to own it.

Managed rules need to be introduced carefully. Legitimate traffic needs to be observed. False positives need narrow corrections rather than sweeping allowlists. Important customer journeys need tests. Virtual patches need to be removed after the underlying vulnerability is fixed. Origins need to be locked down so the edge cannot be bypassed.

The job is not finished when the DNS changes.

The right first step is often detection rather than immediate blocking. Learn what normal traffic looks like, identify the noisy rules, find missing hostnames and understand which requests are expensive. Then move well-understood controls into enforcement.

A badly operated WAF can block customers, miss attacks and create false confidence. That is a reason to operate it properly, not a reason to give the application no independent protection at all.

What a WAF is actually for

A WAF should make exploitation harder, give operators a faster response and reduce what reaches the origin. In practice that means stopping familiar attack traffic, buying time during a vulnerability, putting limits in front of expensive routes and recording enough evidence to explain what arrived.

Developers still own secure design. The WAF gives them another layer, not an exemption.

Our companion article, Everyone Says a WAF Is Useless. Are They Right?, takes the sceptical case seriously. WAFs can be bypassed. They can cause false positives. They create cost and another inline dependency.

Those are real constraints. They define how a web application firewall should be deployed and judged.

They do not change the basic reality: bugs happen, patches take time and bots are cheap. It is sensible to make hostile traffic cross one more independent decision point before it reaches the application.

Everyone Says a WAF Is Useless. Are They Right?

2026-07-28T09:00:00+10:00

Spend long enough around application security and someone will tell you that web application firewalls are useless.

They are easy to bypass. They block real customers. They cannot fix bad code. They cost money, need constant tuning and create one more thing that can fail.

The annoying part is that none of this is entirely wrong.

The mistake is jumping from “a WAF is imperfect” to “a WAF has no useful job”. A lock can be picked. We still lock the door. Security controls are allowed to solve a bounded problem.

So here are ten excellent reasons not to use a WAF—and what they really tell us.

1. “We write secure code”

Good. Keep doing that.

A WAF cannot repair broken access control, fix an insecure password reset flow or stop an application from selling the same scarce ticket twice. Those rules belong in the application because the application understands the customer, the object and the transaction.

But even good teams ship bugs. Dependencies develop vulnerabilities. A vendor patch can take days to test. A legacy application may not have a team at all.

This is where virtual patching earns its keep. A narrowly written WAF rule can block a known exploit while the real fix is prepared. OWASP describes the source-code fix as the preferred answer, while also recognising that an enforcement layer can reduce the exposure window.

Secure code and a WAF are not competing ideas. One fixes the weakness. The other can make it harder to exploit in the meantime.

2. “Attackers can bypass it”

They can.

Researchers have found WAF bypasses using alternative encodings, duplicated parameters and differences between the way a firewall and an application parse the same request. One 2024 study found 311 protocol-level evasion cases across 14 WAFs and 20 web frameworks.

That finding should end any talk of a WAF as a force field. It should not convince us to pass every request straight to the application.

Most hostile internet traffic is not a handcrafted masterpiece. It is scanning, probing and replaying familiar attacks across thousands of sites. Filtering that traffic does not make the application invulnerable. It removes a large amount of cheap, automated opportunity.

A determined burglar may pick a lock. We still lock the door.

3. “WAFs block legitimate customers”

An untuned WAF certainly can.

A product description, support ticket or API request may contain HTML, SQL-like text or unusual characters for perfectly innocent reasons. Turn every managed rule on, switch immediately to blocking mode and the first security incident may be your own checkout failing.

Microsoft recommends starting a new WAF in detection mode, reviewing the logs and tuning it before enforcement. It also says the process may take several weeks.

What this rules out is the Friday-afternoon deployment: every managed rule enabled, blocking turned on and nobody watching checkout.

Start by observing. Find the rules that match real traffic. Make exclusions as narrow as possible. Test important customer journeys. Then block what you understand.

4. “It cannot understand our business”

Correct. This may be the most important criticism on the list.

A generic WAF cannot know that customer A should never see customer B's invoice. It cannot know whether buying 400 concert tickets is normal wholesale activity or scalping. It cannot decide whether a bank transfer fits the customer's history.

Many serious API failures involve valid-looking requests used in the wrong context. The OWASP API Security Top 10 is full of problems involving object ownership, authentication, permissions, resource consumption and sensitive business flows.

Those controls need application context.

There is still work suited to the edge: reject malformed requests, enforce broad limits, filter known exploit patterns and record what reached a sensitive route. A wider WAAP service may also add API schemas, bot signals and account-abuse controls. The application remains responsible for the final business decision.

5. “We already have a CDN”

You may already have the machinery for a WAF. That does not mean it is protecting anything.

Is the managed ruleset enabled? Is it logging or blocking? Does it cover every public hostname and API version? Can an attacker connect directly to the origin? Are large or compressed request bodies inspected? Has anyone reviewed the exclusions since the last application release?

A WAF only protects traffic that passes through it. Cloudflare's own troubleshooting guide says it only mitigates proxied traffic. AWS separately documents how to restrict an origin so visitors cannot bypass CloudFront and reach it directly.

“We have a CDN” is an architecture statement. “All public traffic crosses an active, tested policy” is a security statement.

6. “A WAF will not stop a huge DDoS attack”

Also true.

If an attack fills the network connection in front of an on-premises WAF, the appliance may be functioning perfectly while the website remains unreachable. Volumetric attacks need upstream capacity: an ISP, cloud network, CDN or dedicated scrubbing service able to absorb them before they reach the constrained link.

Application-layer attacks are different. They target expensive searches, login endpoints, uncached pages, GraphQL queries or API operations that consume disproportionate origin resources. Rate limits and request-aware controls can help there.

This is why the distinction between WAF and WAAP matters. A classic WAF filters HTTP requests. A WAAP bundle may combine that with bot management, API protection and application-layer DDoS controls. The acronym does not tell you which controls are included, licensed or switched on.

7. “Bots just rotate their IP addresses”

Yes, and an IP blocklist on its own is a fairly tired answer.

Modern abuse can arrive through residential proxies, mobile networks, cloud platforms and large pools of short-lived addresses. If the only question is “have we seen this IP before?”, the attacker often wins by changing it.

Useful bot management combines several weaker signals: request rate, route, session behaviour, account outcome, headers, network characteristics and browser evidence. The response can vary too. A suspicious request might be logged, slowed, challenged or given a tighter limit instead of being permanently blocked.

OWASP's bot-management guidance makes the goal clear: raise the cost of abusive automation while leaving legitimate people and useful bots alone.

An IP list is easier. It is also further from the problem.

8. “It is another expensive security subscription”

Sometimes it is. WAF pricing can be a peculiar experience because a business may pay to inspect millions of requests it never wanted.

The fair comparison is not “WAF bill versus zero”. It is the WAF bill against origin compute, emergency engineering, fraud, scraping, support calls, application downtime and the cost of investigating an incident with poor logs.

That does not guarantee the WAF wins. A brochure site with no accounts, no API and almost no dynamic input may need little more than sensible CDN protection, origin restriction and good patching. A busy login or checkout path under constant automated abuse has a different calculation.

The control should match the exposure. Buying the largest WAAP bundle available is not a security strategy.

9. “It is not set-and-forget”

No useful security control is.

Applications change. New endpoints appear. Old APIs stay online longer than expected. Managed rules are updated. Attack traffic changes. An exclusion created during an incident quietly survives for three years.

A WAF needs an owner, observable decisions, staged changes and periodic review. Virtual patches need expiry dates. Important customer journeys need regression tests. Logs need someone who will look at them.

If nobody will operate the WAF, that is a legitimate reason not to buy an elaborate one. A permanently ignored dashboard is not defence in depth. It is interior decoration.

10. “Putting it inline creates another point of failure”

It does.

A bad rule can block a site globally. A provider can have an outage. A self-hosted appliance can fail open or fail closed. In 2019, Cloudflare published a detailed account of how a WAF rule containing a poorly performing regular expression exhausted CPUs across its network.

Inline controls need the same engineering discipline as the applications behind them: staged rollout, rollback, monitoring, tested failure modes and a clear way to recover.

The origin, load balancer, DNS provider, identity service and database are points of failure too. We accept those dependencies when the service is worth it, then engineer around their failures. A WAF deserves the same treatment.

So, do you need a WAF?

Maybe not.

If the site is genuinely static, low value and already protected by a capable edge, a premium WAAP service may solve very little. If nobody will tune it, test it or respond to its alerts, the product may create more confidence than protection.

The case becomes much stronger when the application has accounts, payments, personal information, valuable APIs, third-party dependencies, slow patch cycles or a history of automated abuse. It becomes stronger again when the same edge can protect the origin, control bots, limit expensive routes and leave useful evidence for the people investigating incidents.

A web application firewall does not make an insecure application secure. The honest claim is smaller: applications have bugs, patches take time and the public internet is noisy. A well-run WAF gives that noise one more place to stop before it becomes your application's problem.

Two Lineages of TLS Fingerprinting: JA3, JA4 and Cisco Mercury

2026-07-26T09:00:00+10:00

It is tempting to draw the history of TLS fingerprinting as a single line: JA3, then JA4, with Cisco Mercury somewhere nearby. That version is tidy. It is also wrong.

Two strands of work developed around the same observation: a TLS ClientHello exposes enough information to say something useful about the software that created it. One strand concentrated on portable identifiers that could be logged and exchanged. The other concentrated on retaining protocol structure and combining it with evidence that could improve classification.

JA3 and JA4 belong mainly to the first strand. Cisco Mercury belongs mainly to the second. For the technical work that preceded JA3, see how TLS handshakes became fingerprints.

Before JA3

Passive fingerprinting predates TLS. Tools such as p0f identified operating-system characteristics from TCP/IP behaviour without sending probes to the target. Researchers later applied the same instinct to fields exposed during SSL and TLS negotiation.

In 2009, Ivan Ristić published an SSL handshake fingerprinting experiment that compared ClientHello messages from web clients. Marek Majkowski followed with a TLS fingerprinting patch for p0f in 2012. Lee Brotherston's FingerprinTLS later provided tools and a database for creating and matching TLS fingerprints.

Salesforce's JA3 project drew directly on that work. JA3 serialised five ordered ClientHello feature groups, removed GREASE values and calculated an MD5 digest. The result was compact enough to put in a log, share in threat intelligence or match in a rule. The archived JA3 repository documents both the format and its debt to FingerprinTLS.

JA3's compactness came with a cost. A digest does not explain why two clients differ. Ordered inputs also meant that harmless permutation could produce a different value. Most importantly, a matching digest did not prove that the traffic came from one application. Programs built on a shared TLS library could produce the same ClientHello.

The JA4 branch

FoxIO introduced JA4 in 2023 after Chrome began permuting TLS extension order. Peakhour saw the practical effect of that change in our Chrome extension-randomisation analysis: a representation that preserved extension order split one common browser family into a large number of values.

JA4 canonicalises selected ClientHello features before hashing them. Its a_b_c structure keeps a readable summary in the first section, a digest of sorted cipher identifiers in the second, and a digest derived from extensions and signature algorithms in the third. This makes the components useful independently. An analyst can group on part of a JA4 value without pretending every field is identical.

That is deliberate lossy compression. JA4 is useful because it throws away distinctions its designers judged unstable or unhelpful for this job. It is not a reversible rendering of the ClientHello, and its truncated SHA-256 sections do not provide a measure of semantic distance. The exact format is set out in the FoxIO JA4 technical specification.

JA4 is one method. JA4+ is the name used for a wider family that includes server, HTTP, TCP, SSH, certificate and other fingerprints. Those methods do not all share JA4's licence, which matters if the fingerprints will be built into a commercial service.

The Cisco research branch

Cisco's work took a different route. In 2016, Blake Anderson, Subharthi Paul and David McGrew studied how observable TLS features could help distinguish malware from enterprise traffic without decrypting it. Their paper, Deciphering Malware's Use of TLS, also dealt with an awkward issue that still matters: malware-sandbox data can bias a classifier.

Anderson and McGrew's 2017 operating-system fingerprinting research combined evidence from TCP/IP, TLS and HTTP across multiple sessions. The point was not to mint a universally portable hash. It was to ask whether several kinds of passive evidence, accumulated over time, reduced uncertainty about the endpoint.

The same multi-protocol approach appears in Cisco's Joy and Mercury projects. Mercury's Network Protocol Fingerprinting format represents selected protocol features as a tree of hexadecimal byte strings. The full form retains structure. Its naming can state the protocol and fingerprint rule version. An optional compact hash can be used where a fixed-length value is more practical. Cisco's current draft NPF specification defines fingerprints for TLS, QUIC, TCP, HTTP, SSH and other protocols.

Mercury also keeps fingerprint generation separate from process classification. That distinction is easy to miss.

A fingerprint and a label are different things

In Cisco's 2020 paper, Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases, the authors found that common TLS fingerprints mapped to many processes. For the 100 most prevalent fingerprints in their May 2020 data, the median was 24.5 process names per fingerprint.

Their response was not a longer hash. They combined the fingerprint with destination address, port and server name, then used a weighted naïve Bayes classifier backed by a continually updated knowledge base.

That produces an inference, not a property embedded in the fingerprint string. The result depends on labelled observations, their age, the monitored environment and the destination evidence available for the connection. The open Mercury repository can generate fingerprints without possessing Cisco's production knowledge base.

This is the clearest difference between the two lineages:

JA3 and JA4 define portable representations for selected TLS observations.
Mercury NPF retains a richer, versioned representation that can be fed into a separate analysis system.
Mercury's destination-context classifier is another layer again.

None of these layers proves who made a request.

Where the lineages meet

The projects respond to many of the same protocol changes. Both JA4 and recent Mercury formats sort selected TLS fields to reduce instability caused by permutation. Both deal explicitly with GREASE. Both recognise that operators need compact values for logs as well as enough detail to investigate differences.

They make different trade-offs. JA4 is convenient for grouping and interchange. Mercury's full NPF form is better suited to inspection and to analysis that benefits from retained structure. JA4's wider family adds fingerprints for other observations, while Mercury is also a packet metadata collector and protocol-analysis library. Comparing only the length of their hashes misses most of the design.

The lab article makes that concrete. In one ClientHello, three fingerprints, we run JA3, JA4 and Mercury against the same packet capture, record the exact tool versions and compare what each output preserves.

Before JA3: How TLS Handshakes Became Fingerprints

2026-07-19T09:00:00+10:00

JA3 is often treated as the beginning of TLS fingerprinting. It was not. Its real contribution was narrower and, operationally, just as important: JA3 took a set of ideas that had been explored for years and turned them into a small identifier that ordinary security tools could carry.

The path to that format runs through an SSL Labs experiment in 2009, an experimental p0f extension in 2012 and Lee Brotherston's FingerprinTLS work in 2015. Each step answered a different question. What can the cleartext handshake reveal? Which details survive often enough to identify a client? How do you turn those details into something an analyst can match? And, finally, how do you make the result portable?

This is a documented lineage where the authors themselves cite the earlier work. The claim that JA3's decisive move was simplification is our interpretation of those sources, not a claim that every project shared one design plan.

2009: the cipher list as a client signature

In June 2009, Ivan Ristić described an experiment in HTTP client fingerprinting using SSL handshake analysis. He was working on SSL Labs and noticed a useful property of the initial handshake: clients sent different lists of supported cipher suites, and those lists were visible before encryption began.

The important observation was not that any one cipher identified a browser. It was the combination of ciphers a client offered. Ristić recorded the entire list as a signature and compared it with the HTTP User-Agent seen after the connection was established. He then published examples collected from real SSL handshakes, showing that the approach could separate a range of browsers, command-line clients and crawlers.

This early method was deliberately modest. It concentrated on the cipher-suite list. It did not define a general-purpose fingerprint containing every useful ClientHello feature, and it did not claim that a signature proved the identity of a process.

Even so, the core technical idea was in place:

unencrypted ClientHello
  -> implementation-dependent choices
  -> repeatable signature
  -> comparison with previously observed clients

The handshake was no longer just cryptographic setup. It was passive metadata about the software constructing it.

2012: p0f adds order, extensions and matching rules

Marek Majkowski pushed the idea further in his 2012 SSL fingerprinting patch for p0f. p0f was already known for passive operating-system fingerprinting at lower layers. Majkowski applied a similar signature-and-database model to SSL and TLS ClientHello messages.

His post explicitly credits Ristić's 2009 work, then points to two details he believed deserved more attention: ordering and TLS extensions. The patch represented a fingerprint as four fields:

requested version : ordered ciphers : ordered extensions : flags

That is a meaningful technical step. Cipher suites are normally sent in preference order, and extension order can differ between implementations. Retaining those sequences gives the signature more discriminatory power than an unordered inventory. The flags recorded other behaviours, such as compression support or an unusual relationship between record and handshake versions.

The implementation did more than print a string. It matched the result against a database of signatures that could contain wildcards and return a browser family, possible versions and sometimes a platform. The original p0f patch and notes are still useful because they expose the boundary between observation and label: one part generates the raw signature; another compares it with knowledge gathered elsewhere.

Majkowski also wrote with appropriate caution. His notes say that a ClientHello can sometimes identify the underlying SSL library and, for software with a custom build or distinctive feature set, may narrow the application version. "Sometimes" matters. Two applications using the same TLS stack can look alike, while one application can change its handshake when its library, configuration or build changes.

The p0f work did not become the universal exchange format for TLS fingerprints. It did, however, demonstrate most of the ingredients that later systems would reuse: selected fields, preserved order, a serialised signature and a separate matching database.

2015: FingerprinTLS turns a method into a toolset

Lee Brotherston's 2015 work expanded the practical surface again. His DerbyCon and SecTor presentation, Stealthier Attacks and Smarter Defending with TLS Fingerprinting, examined TLS fingerprinting from both sides: defenders could recognise unexpected software, while an operator could alter a client's handshake to blend in or evade a simplistic rule.

The associated FingerprinTLS repository packaged the approach into several working parts:

FingerprinTLS detected TLS sessions on a live interface or in a PCAP, created fingerprints and matched them;
fingerprints.json stored the known fingerprint database;
Fingerprintout exported observations into other forms, including Snort and Suricata rules.

This was broader than calculating a digest. It was a workflow for capturing a handshake, retaining many of its characteristics, associating that observation with known software and moving the result into operational tools.

The project also made an awkward truth visible: rich fingerprints are not especially convenient interchange formats. FingerprinTLS could inspect more detail, but exporting that detail into a rule language could lose accuracy. Its README warned that Snort and Suricata exports might require tuning because their rule syntax could not express the full matching logic.

That trade-off set the stage for JA3. A detailed signature helps an analyst explain why two handshakes differ. A compact value is easier to add to a connection log, compare across sensors and share with another team. It is difficult to optimise one representation for both jobs.

2017: JA3 chooses portability

Salesforce open-sourced JA3 in 2017. John Althouse's original JA3 announcement directly cites Ristić's 2009 post and Brotherston's 2015 research. It also states the team's design requirement plainly: the result had to work with existing monitoring systems and load balancers, be independent of the destination, and be easy for other tools to consume.

JA3 selected five ordered ClientHello feature groups:

TLS version,
cipher suites,
extension types,
supported groups,
elliptic-curve point formats

It rendered their numeric values into a comma-separated string, removed GREASE values, then calculated an MD5 digest. A long handshake description became a 32-character identifier.

MD5 was not being used here to protect a password or prove integrity. It was a compact naming function. The security weakness of MD5 still means a JA3 value should not be treated as proof, but changing to a stronger digest would not solve the more common identification problem: unrelated software can naturally produce the same selected features, and software can deliberately copy another client's ClientHello.

The simplification was substantial. Compared with FingerprinTLS, JA3 retained fewer fields and discarded the explanatory structure once the string was hashed. Compared with the p0f patch, it did not carry matching wildcards or classification rules in the fingerprint. What it gained was a common unit that could fit almost anywhere an operator could put a string.

That was why JA3 travelled. A sensor could calculate the value, a SIEM could index it, an intelligence report could publish it and a rule could match it without every participant adopting the same fingerprint database or packet parser.

What JA3 inherited, and what it left behind

The documented history supports a few specific claims:

Ristić showed in 2009 that an unencrypted SSL handshake, particularly its cipher list, could distinguish HTTP clients.
Majkowski's 2012 p0f work explicitly built on that experiment and added ordered extensions, behavioural flags and database matching.
Brotherston's 2015 research and FingerprinTLS made detailed capture, matching, creation and export available as a standalone toolset.
Salesforce cited the earlier work when it released JA3 and designed a smaller representation for existing operational systems.

It does not support treating a fingerprint as an application identity. Every stage depended on a set of observed features and, when a software name was returned, knowledge collected outside the handshake itself. The label could be useful without being certain.

That distinction is easier to see when the formats are run side by side. Our reproducible lab feeds one ClientHello to JA3, JA4 and Cisco Mercury and records both the compact outputs and the detail each format preserves.

JA3 was not the final step either. JA4 later changed the normalisation and output structure to cope with modern sources of instability, while Cisco's research followed a more structured, context-aware path. Those are separate branches, not one straight succession. We trace them in Two Lineages of TLS Fingerprinting.

The useful lesson from the early history is not who coined the first fingerprint. It is that the representation determines the work you can do with it. Rich detail helps investigation. Compact identifiers help distribution. Neither turns a handshake into an identity document.

A Network Fingerprint Is a Cohort, Not a Client

2026-07-13T09:28:00+10:00

A TLS fingerprint usually tells you that two connections look alike under a particular set of rules. That is useful. It is not the same as showing that they came from the same client.

The distinction becomes obvious when a common TLS library sits underneath many programs. Those programs can offer the same protocol version, cipher suites, extensions and signature algorithms. A fingerprint built from those fields groups them together even though their purpose, owner and risk are different.

The reverse also happens. One application can generate several fingerprints after a browser update, operating-system change, feature rollout or configuration difference. A fixed application name does not imply a fixed ClientHello.

The safest mental model is a cohort: traffic that looks the same after a fingerprint method has selected and normalised its inputs.

The method defines the cohort

JA3 preserves the order of its selected ClientHello feature lists. Change the order and the MD5 value changes. JA4 sorts selected identifiers before calculating two of its components, so permutations that split a JA3 cohort may remain grouped under JA4.

Cisco Mercury can preserve more packet-derived structure in its full Network Protocol Fingerprint. Different Mercury rule versions also make different normalisation choices. A tls/2 value is therefore not just a longer spelling of JA4. It is the result of another feature-selection contract.

This means there is no format-independent "real fingerprint" hiding underneath the tools. Each method answers its own equivalence question: which differences count, and which should be ignored?

Our same-PCAP lab demonstrates that point without relying on a hypothetical browser. The three tools inspect the same ClientHello and produce representations with different retained detail.

Common does not mean safe

A popular browser fingerprint will naturally appear in a great deal of legitimate traffic. An attacker can also use a browser, drive one through automation, or imitate its TLS stack. Matching a common browser value therefore says little about intent by itself.

The opposite shortcut is just as risky. An uncommon fingerprint is not proof of malware. Internal tools, older mobile applications, embedded devices, accessibility software and regional client variants can all be rare in one dataset.

Rarity is relative to the observation point. A fingerprint that is common across a public content site may be unusual on an administrative API. A value common in one country, network or month may be rare in another.

Capture point changes what you see

TLS fingerprinting only works where the relevant handshake is visible. At an origin behind a CDN or reverse proxy, the TLS connection may have been terminated and replaced upstream. The origin can then observe the proxy's connection rather than the end user's ClientHello unless the edge explicitly forwards a derived fingerprint.

That forwarded value also needs provenance. Operators should know which implementation and format version produced it, whether it came from the client-facing connection, and whether middleware transformed or sampled the traffic.

Without that information, two values that look compatible may have been generated under different rules. Fastly has documented how implementation differences can undermine the portability promised by a shared hash in The State of TLS Fingerprinting.

Context can improve an inference

Cisco's Mercury research is helpful because it does not hide the ambiguity. The 2020 destination-context paper reports that one TLS fingerprint often maps to tens or hundreds of process names. Its classifier adds destination IP address, port and server name, backed by a labelled knowledge base, to rank the possible processes.

That is stronger than treating a bare fingerprint as an application name. It is still conditional. Change the environment, the age of the knowledge base, the available destination fields or the software population and the probabilities can change. The paper's reported accuracy belongs to its datasets and experimental design, not to every network that runs Mercury.

JA4 deployments often add context too. A security platform might combine the JA4 value with request rate, geography, path, account state or observations from other customers. Those extra fields are not secretly part of JA4. They are features in the surrounding detection system.

Use fingerprints where grouping helps

Fingerprints earn their place when grouping similar connections improves an investigation or control. Examples include:

counting login failures across rotating IP addresses;
finding a TLS stack that appeared at the start of an incident;
comparing a claimed browser with HTTP and browser-side evidence;
monitoring drift after a client or library release;
selecting traffic for review before writing a narrower rule.

For the decision and enforcement consequences, see Fingerprints are evidence, not identity. The protocol-specific conclusion here is narrower: a matching TLS fingerprint places connections in a cohort defined by one method. It cannot tell you, on its own, who is on the other end.

The practitioner follow-up, Using network fingerprints in bot and rate-limit decisions, turns that boundary into a route-scoped policy and rollback model.

From Joy to Mercury and EVE: Following Cisco's Network Fingerprinting Work

2026-07-13T09:28:00+10:00

Cisco's network fingerprinting work is often compressed into a neat product story: Joy became Mercury, and Mercury became the Encrypted Visibility Engine. There is a real lineage here, but that sentence hides more than it explains.

Joy and Mercury are public software projects. Network Protocol Fingerprinting is a representation. The 2020 destination-context paper describes a classification system and the data needed to support it. EVE is a Cisco Secure Firewall capability backed by Cisco's operational data and machine-learning systems.

Those pieces share ideas, authors and engineering history. They are not four names for the same thing.

Joy started with flow records, then looked inside them

Cisco released Joy as a BSD-licensed tool for collecting network flow and intraflow data from live traffic or PCAP files. Its basic unit was recognisable to anyone who had worked with NetFlow or IPFIX: a flow with addresses, ports and counters. Joy then added observations from within that flow.

Those observations included packet lengths and arrival times, byte distributions, TLS record sequences, visible TLS handshake fields, DNS data and selected HTTP fields. It wrote the results as JSON so researchers could feed them into analysis tools without building a packet parser first.

That breadth matters. Joy was not originally just a ClientHello hash generator. It was a network-research instrument for asking what could still be learned from traffic when the application payload was encrypted.

The research around Joy shows how Cisco used it. The 2016 paper Deciphering Malware's Use of TLS (without Decryption) combined conventional flow measurements, packet-length and timing sequences, byte distributions and visible TLS handshake features. Its authors were interested in malware detection and family attribution, but they were also explicit about dataset bias. A sandbox operating system or its default TLS library could become an accidental shortcut for the classifier.

In 2017, OS Fingerprinting: New Techniques and a Study of Information Gain and Obfuscation used an extended Joy collector to record features from TCP SYN packets, TLS ClientHello messages and HTTP requests. The study combined evidence across protocols and sessions rather than expecting one handshake to provide a definitive operating-system label.

The enduring idea was broader than any one model: retain useful network observations, join them to trustworthy labels where possible, and test what the combined evidence can support.

Mercury narrowed and hardened the collection path

The Joy repository now directs readers to Mercury for Cisco's more recent fingerprinting tools and data. Mercury carries forward the packet-metadata and JSON-output model, but it is a separate implementation with a stronger focus on fast capture, protocol fingerprints and online analysis.

The public repository contains a C++ application and library, along with the portable Python implementation pmercury. Mercury can read PCAPs or live traffic, identify supported protocols and emit selected metadata. On Linux, its native collector uses the kernel's AF_PACKET TPACKETv3 path and multiple workers. The repository describes use in some production applications, while still asking users to treat the open software as beta.

Mercury also makes a useful boundary visible in its JSON:

packet
  -> protocol metadata
  -> fingerprint object
  -> optional destination-context analysis
  -> analysis object

The fingerprint is an observation. The analysis is an inference made from that observation and other data. They should not be collapsed into one label.

NPF is the representation, not the classifier

Mercury's fingerprints use Cisco's Network Protocol Fingerprinting format. NPF selects characteristic fields from an initial protocol message, normalises values that should not distinguish implementations, and writes the retained structure as a tree of hexadecimal byte strings.

A full TLS fingerprint can therefore be inspected. Its tls/2 prefix identifies the protocol and rule version; parentheses and brackets preserve the selected tree structure and sorting decisions. Mercury can also use a compact hash nickname when fixed-length storage is more useful than inspection.

The draft NPF specification covers more than TLS. It documents rules for protocols including QUIC, TCP, HTTP, SSH, STUN and OpenVPN. This is one point at which the Joy heritage remains visible: the project treats protocol evidence as a network-wide problem, not solely as a way to name TLS clients.

Our guide to Cisco Mercury fingerprinting separates the collector, NPF representation, knowledge base and classifier in more detail. Inside a Mercury NPF fingerprint works through the full notation.

The 2020 paper made the attribution problem explicit

A fingerprint is useful for grouping similar protocol implementations. It is often a poor application name.

Blake Anderson and David McGrew quantified that problem in Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases. TLS libraries are shared. Common fingerprints can map to tens or hundreds of processes. A dictionary that assigns one process name to one fingerprint will therefore produce convincing-looking false positives.

The paper added three destination features to the TLS fingerprint: destination address, destination port and the TLS server name, when present. A weighted naive Bayes classifier used those features and prevalence counts from a labelled knowledge base to rank candidate processes.

The knowledge base was the difficult part. The researchers joined network observations to endpoint process data, generated fresh knowledge bases daily and merged them into an operational view. They also used malware-sandbox observations. The paper describes billions of connections, a changing population of fingerprints and destinations, and the need to discard stale data.

Its reported results were strong, including a process-family F1 score above 0.99 and high precision and recall for the malware task. Those figures belong to the paper's datasets and evaluation. They are not an accuracy guarantee for a Mercury installation downloaded from GitHub.

The authors also documented important limits: their endpoint data was dominated by desktop Windows and macOS systems, mobile and IoT coverage was absent, and most data came from one enterprise. They wrote that a site could build a custom knowledge base if it had suitable endpoint ground truth and network monitoring, but acknowledged the significant initial investment.

That is the operational lesson. A classifier is not made current by having a good fingerprint format. It stays current through labelled collection, joining, curation, expiry and evaluation.

For a closer reading, see how destination context changes TLS attribution.

EVE puts the research into a firewall product

Cisco describes its Encrypted Visibility Engine as work based on that earlier destination-context research. EVE first appeared in Secure Firewall 7.1 as a disabled-by-default experimental beta for visibility only; it did not enforce actions and Cisco warned that it could produce false positives. The 7.2 release notes say EVE began working with QUIC and allowed high-confidence process assignments to feed application policy. Version 7.3 specifically added HTTP/3 and SMB-over-QUIC detection, along with indication-of-compromise events for unsafe applications.

In Cisco's account of how EVE detects malicious use of trustworthy cloud services, the runtime inputs have the same recognisable shape:

an NPF representing client-side protocol characteristics; and
server context such as address, port and domain name.

EVE uses machine learning over Cisco's labelled data to estimate the client process and detect suspicious encrypted traffic without decrypting its payload. Cisco says its training data is refreshed daily with network samples joined to endpoint ground truth, with additional malicious observations from Cisco Secure Malware Analytics.

This is the clearest public link from NPF and the 2020 paper to the commercial system. It is also where careful wording matters most.

The public Mercury repository is not a source release of the complete EVE service. Building Mercury does not provide Cisco's continuously collected production dataset, its current models, Secure Firewall integration, Talos context or product policy behaviour. Conversely, the fact that EVE uses NPF does not mean every detail of its current implementation is present in the open repository or frozen at the method described in the 2020 paper.

Open code, published research and a maintained security product have different release cycles and different evidence behind them.

What the lineage actually establishes

There is a coherent progression:

Joy
  broad flow and intraflow metadata for research

Mercury + NPF
  faster collection and versioned, multi-protocol fingerprints

2020 destination-context system
  fingerprints joined to destinations and endpoint labels

EVE
  Cisco-maintained classification in Secure Firewall

This is a lineage of ideas and systems, not a promise that each box is a drop-in edition of the next one.

Joy established a practical way to collect visible evidence around encrypted flows. Mercury made protocol fingerprinting a more explicit and efficient part of that collection. NPF gave those fingerprints a structured, versioned form. The destination-context work showed why labelled, continuously refreshed context was necessary for process attribution. EVE operationalised those ideas inside a commercial firewall environment with data and integrations that do not ship with the public collector.

That history also explains why Cisco's branch of fingerprinting developed differently from JA3 and JA4. A portable hash is useful for logging and exchange. Cisco's work kept returning to a harder question: what additional evidence, labels and maintenance are required before a network observation can support a process assessment?

Neither approach turns a handshake into identity. Our two lineages of TLS fingerprinting article places Cisco's work alongside JA3 and JA4. The reproducible one ClientHello, three fingerprints lab shows the format differences without relying on any vendor classification database.

What an Open Network Fingerprint Database Should Publish

2026-07-13T09:28:00+10:00

An open fingerprint database should let another researcher disagree with it.

That requires more than a hash and an application name. The row needs to show which bytes produced the fingerprint, how the label was established, where the traffic was observed, which software generated the value and what competing explanations remain plausible.

Most public databases were built for a narrower purpose. Historical JA3 lists made values easy to share. Threat feeds made malware observations easy to match. Nmap and p0f made signature rules executable. TLS observatories count what appears at their vantage points. Those are sensible designs for their jobs.

They do not yet add up to a reusable open ground-truth corpus.

Start with observations, not verdicts

The fundamental database object should be an observation:

{
  "observation_id": "...",
  "observed_at": "2026-07-12T00:00:00Z",
  "capture": {
    "position": "client-facing edge",
    "collector": "mercury",
    "collector_revision": "3172786...",
    "source": "controlled-client-run"
  },
  "fingerprints": [],
  "labels": [],
  "evidence": [],
  "licence": "..."
}

The observation can then carry several fingerprint methods and several candidate labels. This is safer than making the hash the primary truth and forcing one application name into the same row.

Store the reversible material

Each fingerprint entry should contain the published identifier and the material used to derive it:

{
  "method": "ja4",
  "implementation": "FoxIO Python",
  "implementation_revision": "...",
  "value": "t12d2709h2_..._...",
  "raw_value": "t12d2709h2_002f,...",
  "source_message_digest": "sha256:...",
  "truncated": false
}

For JA3, retain the five-part source string beside the MD5. For JA4, retain JA4_r where collection policy permits it. For Mercury, retain the complete versioned NPF string rather than only its hash nickname. For HASSH, retain the algorithm lists. For a matcher rule, retain the response bytes or sanitised fixture that satisfied it.

This permits field-level comparison, implementation testing and migration when a definition changes. It also exposes incompatible values hidden behind a common field name.

Make labels many-to-many

Labels should be separate evidence-backed assertions:

{
  "type": "process",
  "value": "example-client",
  "version": "1.2.3",
  "source": "endpoint-telemetry-join",
  "review_state": "reviewed",
  "confidence": 0.94,
  "first_seen": "...",
  "last_seen": "..."
}

One fingerprint can have several process labels because applications share libraries. One process can have several fingerprints because versions, platforms and configurations differ. The schema should preserve counts and conflict instead of selecting one winner during ingestion.

Cisco Mercury's public resource schema points in this direction: fingerprint entries contain candidate processes, observation counts, operating systems and destinations. The production database is private, but the many-to-many model is the right starting point.

Describe how ground truth was produced

Use a controlled vocabulary for evidence sources:

controlled_capture
endpoint_process_join
malware_sandbox
reviewed_pcap
active_probe_match
passive_observation
community_submission
derived_from_external_database

Each type needs its own metadata. An endpoint join should record the join window and ambiguity rules. A controlled capture should name the client build, operating system and generation script. A malware sandbox label should identify the sample and distinguish the sandbox process from the malware process. A community submission should identify what a reviewer actually checked.

Derived labels should never masquerade as independent evidence. If a mapping was imported from an older JA3 list, cite that row and keep its original uncertainty.

Separate prevalence from classification

Prevalence belongs in observation aggregates:

{
  "source": "university-vantage-a",
  "first_seen": "...",
  "last_seen": "...",
  "count": 184233
}

It should not silently increase application-label confidence. A common fingerprint is not necessarily well-labelled; a rare fingerprint is not necessarily suspicious.

The TLS Fingerprint Observatory demonstrates the value of publishing counts even when labels are missing. Its large unlabelled TLS corpus is more useful for prevalence research than a catalogue filled with guesses.

Represent threat observations explicitly

A malware feed should attach an observation, not overwrite the fingerprint's identity:

{
  "type": "malware-sandbox-observation",
  "family": "example-family",
  "sample_sha256": "...",
  "observed_at": "...",
  "known_good_evaluation": "not-performed"
}

This retains the warning published by sources such as SSLBL. It allows a consumer to ask whether a fingerprint was seen in malware without treating every matching benign process as infected.

Publish validation sets and negative evidence

A useful database should include:

controlled positive captures;
known-good observations that share supposedly malicious fingerprints;
deliberately conflicting labels;
client upgrades that changed fingerprints;
malformed and truncated handshakes;
captures before and after a TLS-terminating proxy;
implementation conformance cases.

Negative and conflicting evidence is not database dirt. It tells consumers where a label stops working.

Version the data and the interpretation

Every release should state:

schema version;
database snapshot identifier;
fingerprint implementation revisions;
collection time range;
label additions, removals and merges;
retired mappings;
licence changes;
reproducible validation results.

Consumers should be able to pin a snapshot and explain which database caused a decision. A live service may remain convenient, but an incident review needs the state that existed when the event was classified.

Make licensing part of the schema

Fingerprint method, implementation and dataset rights are separate.

Core JA4 is BSD-licensed. Other JA4+ methods use different FoxIO terms. Nmap's data files use the Nmap Public Source License. A combined historical repository may contain rows imported under different licences. An API may permit lookup but prohibit bulk redistribution.

Store a licence or source-rights reference for each imported dataset and, where necessary, each record. If the rights are unclear, publish a pointer and transformation recipe rather than republishing the row.

Provide a confidence model that can be audited

A score without calibration is decoration. For each label type, document:

what the score estimates;
the labelled validation set;
true-positive and false-positive definitions;
treatment of unseen applications;
time and environment holdouts;
how conflicts and stale observations affect the score.

Where calibration is unavailable, use review states such as submitted, reproduced, reviewed and contested instead of inventing numeric precision.

The minimum viable open record

If full packet evidence cannot be published, a useful minimum is:

method and rule version
implementation revision
compact and raw fingerprint
candidate label, including version/platform
ground-truth method
capture position
first and last seen
observation count
confidence or review state
evidence reference
licence

That is more expensive than a CSV containing hash,name. It is also what makes the mapping useful outside the environment and assumptions of its original collector.

The public ecosystem already contains most of the parts: JA4DB's cross-method model, the TLS observatory's prevalence data, Mercury's candidate-process and destination schema, FingerprinTLS's retained ClientHello fields, and executable fixtures in matcher projects such as Rapid7 Recog. The missing step is to combine those strengths without erasing provenance.

For the current resource landscape, see Public Network Fingerprint Databases and What They Cover. For the import checklist, see How to Evaluate a Network Fingerprint Database.

Public Fingerprint Databases Are Not Ground Truth

2026-07-13T09:28:00+10:00

Network fingerprint formats are public. Reliable labels are not.

We reviewed the main public JA3, JA4, TLS, TCP, HTTP, SSH, JARM, DHCP, operating-system and service-fingerprint resources. The result was not one large ecosystem of interchangeable databases. It was a set of much narrower things: small mapping samples, old signature lists, active-probe rules, malware feeds, account services and a large observatory whose TLS records are almost entirely unlabelled.

That is not a criticism of the maintainers. It is a warning about what happens after a fingerprint field reaches a dashboard. A precise-looking value invites a precise-looking name. The evidence behind that name may be a controlled capture, a best guess from 2018, a community submission or a malware sandbox observation that was never compared with benign traffic.

Those labels should not produce the same decision.

The largest public TLS database has almost no TLS labels

The relaunched TLS Fingerprint Observatory is an unusually valuable public resource. It exposes more than a million distinct TLS fingerprints and billions of passive observations from the University of Colorado Boulder and Merit Network. Records can include first and last seen, counts by source, cipher suites, extensions, groups, signature algorithms, ALPN and other parsed fields.

At the time of our review, essentially none of the TLS fingerprints had implementation labels.

That fact makes the observatory more credible, not less. The collection can answer prevalence and protocol-evolution questions without pretending it knows which application created every handshake. Its smaller QUIC corpus has several hundred controlled labels, often tied to generated capture files.

The limitation is equally clear. A prevalence database cannot become a browser or malware classifier merely because its records are detailed. The labels require another source of truth.

The public JA4 database is a sample, not JA4DB

FoxIO maintains JA4DB, a hosted service covering several JA4-family methods, applications and detection guidance. It is the closest current service to a multi-surface mapping database.

The public file most people can inspect is different. FoxIO's ja4plus-mapping.csv contains 66 data rows. Only 35 carry a core JA4 value; the other JA4+ columns are sparser.

That file is useful documentation. It shows how an application, library, device, operating system and several network observations can sit in one row. It is not broad enough to serve as a general browser, bot or malware catalogue.

The hosted service is now account-oriented. Its bulk-data licence and per-record provenance are not publicly clear enough to call it an open database. Core JA4's BSD licence does not automatically cover the hosted labels, and it does not cover all other JA4+ methods under the same terms.

The open JA3 mappings are mostly historical

Salesforce's archived JA3 lists contain roughly 159 application mappings for macOS and Linux. The repository describes them as example or best-guess material. They have no per-row capture date, client version, source PCAP or confidence.

Trisul's ja3prints is larger: 626 JSONL mappings assembled from Salesforce examples, malware-traffic-analysis captures, FingerprinTLS and browser additions. Its last update was in 2018, and the combined dataset does not have a clear repository-wide licence.

The historical FingerprinTLS database preserves richer ClientHello fields than JA3, which makes it valuable for research. It is now archived, and many records lack consistent capture dates, operating-system evidence and confidence.

These sources still matter. They document the lineage and can help with an older incident. They should not silently become current application ground truth.

Rules are not observations

Some of the strongest public databases are actually matcher corpora.

Nmap's OS database contains actively maintained probe-response signatures. Nmap service probes combine test payloads with regular expressions that extract products and versions. Rapid7 Recog maintains XML signatures for SSH, HTTP, SNMP, favicons, JARM and other surfaces. p0f's p0f.fp contains passive TCP and HTTP traits, although its upstream corpus is now dated.

These resources can be excellent at their stated job. A rule match means that a response satisfied the signature. It does not establish population prevalence, exclusivity or a particular process behind the connection.

Flattening a matcher result into the same table as an observed application mapping discards that distinction.

Malware observation is not malware identity

SSLBL publishes a JA3 blacklist under CC0. It records fingerprints observed while analysing more than 25 million malware PCAPs and offers both CSV and Suricata rules.

SSLBL also says the values were not tested against known-good traffic and may cause substantial false positives.

That warning is part of the data. A row supports this statement:

malware samples assigned this family label produced this JA3

It does not support this statement:

every connection with this JA3 is that malware

Shared libraries make the second statement unsafe. Cisco's destination-context research examined public malware JA3 indicators and found that many were more strongly associated with benign processes in its enterprise observations.

VirusTotal's behavioural pivots have the same boundary. Files sharing a JA4 may be related malware, come from one developer or merely use the same TLS library. The pivot begins an investigation; it does not finish one.

Mercury publishes the schema, not the labels

Cisco Mercury offers one of the clearest public designs for a fingerprint knowledge base. Its resource documentation describes mappings from fingerprints to candidate processes, process counts, operating-system observations and destinations. The classifier can use destination address, port and server name to rank those candidates.

The current Cisco-labelled resource database is not in the public repository.

This is an honest architectural boundary. The NPF format, collector and database contract are inspectable. The production labels depend on continuously collected endpoint, network and malware-analysis data that Cisco does not publish as an open corpus.

What is actually missing

The public ecosystem does not mainly need another hash list. It needs evidence attached to each mapping:

the raw or reversible fingerprint;
the method and implementation version;
an independent label source;
capture position and environment;
first and last seen;
observation count;
competing labels;
confidence and review state;
a usable dataset licence.

Almost none of the public resources supplies all of these. Some optimise for scale, some for current labels, some for inspectability and some for rules that can run in an existing scanner.

The practical response is to preserve those categories. Use an observatory for prevalence, a matcher corpus for response signatures, a threat feed for malware observations, and a mapping database for candidate labels. Then validate the result against local evidence before it reaches enforcement.

The full directory is in Public Network Fingerprint Databases and What They Cover. The evaluation checklist is in How to Evaluate a Network Fingerprint Database.

Does TLS Fingerprint Canonicalisation Hide Attacker Variation? How to Test It

2026-07-13T09:28:00+10:00

Canonicalisation solves a real problem in TLS fingerprinting. If two ClientHello messages differ only because a client shuffled its extensions, treating them as unrelated fingerprints creates noise. Sorting those extensions puts the messages back into one cohort.

It also destroys the original order.

That is not automatically a mistake. A fingerprint is useful partly because it ignores variation that does not help with the job at hand. The unanswered question is whether some of the discarded variation separates ordinary client behaviour from automation, scanners or deliberate evasion.

Our one-ClientHello lab cannot answer that. It proves that three pinned implementations produce recorded representations from the same bytes. It says nothing about a population of clients or attackers. Answering the canonicalisation question needs a corpus and a labelled experiment.

What gets collapsed?

JA3 removes GREASE values but otherwise preserves the order of the selected cipher, extension, supported-group and point-format lists. Change one of those ordered inputs and the MD5 digest changes.

JA4 deliberately defines a broader equivalence class. Its canonical b section hashes sorted cipher identifiers. Its c section hashes sorted extension identifiers followed by signature algorithms in their advertised order. SNI and ALPN extension codes are omitted from that list because related information is represented in the readable a section. FoxIO's JA4 specification documents those choices.

Cisco Mercury makes the rule version visible. In the current draft NPF specification, the older unversioned TLS format retains extension order, tls/1 sorts all represented extensions, and tls/2 sorts selected extensions while applying more specific inclusion and normalisation rules.

These methods do not merely encode the same fingerprint differently. They define different ideas of “the same”.

Why Chrome forced the issue

Chrome's extension permutation rollout showed why order-sensitive identifiers can become operationally brittle. Peakhour's 2023 analysis recorded a sharp rise in unique order-sensitive signatures after the change. The browser family had not suddenly split into thousands of independent TLS implementations. Much of the new variation came from ordering.

Sorting is an effective response if the goal is to recover the implementation cohort. It is also consistent with Chrome's stated reason for making the change: servers and middleboxes should not depend on one fixed extension order.

But an analyst may have another question. Does a tool permute extensions using the same mechanism and constraints as the browser it imitates? Does a scanner generate an ordering distribution that differs from Chrome's? Does malware preserve the static order supplied by its TLS library while claiming a Chrome user agent?

A canonical JA4 can group those handshakes even when their ordering behaviour differs. That is expected. JA4 answered the cohort question, not every possible behavioural question.

The wrong experiment

Counting how many unique raw fingerprints map to one canonical fingerprint is a useful descriptive statistic. It is not, by itself, evidence that canonicalisation weakened detection.

A common browser with extension permutation should produce many raw orders. A large raw-to-canonical ratio may therefore be evidence of normal deployment scale. Calling every collapsed value a loss of “fidelity” assumes that all variation was useful before the test has measured its relationship with any outcome.

The reverse shortcut is also wrong. Stable canonical values do not prove that sorting is harmless for every detector. A field can be poor for application identification but useful for distinguishing one implementation path, library version or evasion technique.

The experiment needs labels and a defined decision.

A testable study design

We would structure the study around observations, transformations and outcomes.

1. Preserve the original ClientHello

Store the permitted raw handshake metadata or a reversible representation alongside derived identifiers. Record:

capture point and TLS termination path;
sensor implementation and revision;
timestamp and software-release period;
JA3 source string and digest;
JA4, JA4_r, JA4_o and JA4_ro where the implementation provides them;
a full, versioned Mercury NPF string;
HTTP and browser claims kept separate from the TLS representation.

Without the raw or reversible material, a later study cannot recover the ordering that canonicalisation removed.

2. Define labels that do not come from the fingerprint

Labels need an independent source. Depending on the environment, that could include controlled browser runs, endpoint process telemetry, sandbox execution, signed test clients or reviewed incident cases.

Do not label traffic as Chrome because its JA4 resembles Chrome and then report that JA4 identifies Chrome. That is circular evaluation.

Cisco's destination-context research used joined endpoint and network observations to build process labels. The paper also discusses how sandbox and environment choices affect the resulting knowledge base. Accurate TLS Fingerprinting Using Destination Context and Knowledge Bases is useful here because it treats ground truth as a system component rather than a list of famous hashes.

3. Compare representations at the same grouping level

Measure at least:

raw ordered representation;
canonical JA4;
useful JA4 component combinations such as JA4_ac;
Mercury rule versions that preserve or sort different structures;
raw ordering features added beside the canonical value.

The comparison should use the same captures, time split and labels. Otherwise a newer fingerprint method can appear better simply because it was evaluated on newer or cleaner data.

4. Use time and environment holdouts

Randomly splitting individual connections leaks near-duplicates between training and test data. Prefer a forward time split and, where possible, a separate network or capture environment.

That exposes two operational questions: does the result survive a browser or library update, and does it survive outside the environment where the labels were collected?

5. Measure decisions, not just uniqueness

Useful measurements include:

collision and fragmentation rates by independently labelled client;
precision and recall for a stated classification or detection task;
false-positive rates on high-volume legitimate cohorts;
stability across software releases;
the incremental value of raw order after canonical identifiers and context are already present;
review volume at an actual alert or policy threshold.

If adding original order improves a classifier by a tiny amount but creates millions of unstable keys, the operational cost may outweigh the gain. If it separates a specific impersonation technique with few false positives, keeping it as a secondary feature may be worthwhile.

Keep both when the questions differ

The design choice does not have to be raw or canonical.

A compact canonical identifier is useful for grouping, counters, joins and rules. A raw or reversible representation is useful for investigation, feature research and migration when the canonical rules change. Storage policy can keep the compact value broadly and retain detailed material for a bounded sample, selected security events or an approved research window.

That split also makes detector claims easier to audit. The rule can say it grouped on JA4 while the event retains enough source material to explain which handshake produced the value.

What we can say now

Sorting removes ordering information. It reduces fragmentation caused by clients that permute their lists. Both statements follow from the format definitions and can be demonstrated with controlled captures.

Whether the removed order contains useful attacker variation is an empirical question tied to a dataset, capture point, label source and decision. Until that study is run, the honest position is to preserve the evidence needed to test it and avoid turning either uniqueness or stability into a claim of detection accuracy.

For the wider format comparison, see Mercury vs JA4 vs JA3. For the identity boundary that applies to every result, read A network fingerprint is a cohort, not a client.

Using Network Fingerprints in Bot and Rate-Limit Decisions

2026-07-13T09:28:00+10:00

A network fingerprint is a useful rate-limit key. It is a poor verdict.

That sounds like a small distinction, but it changes how a control behaves. A limit keyed only by source IP can miss a distributed scraper moving through thousands of addresses. Add a TLS or HTTP fingerprint and the requests may fall into a recognisable cohort. The operator can count and compare them even while the IPs rotate.

The same key can also group thousands of ordinary users running the same browser release. If the control reads “this fingerprint is a bot” and blocks it everywhere, the grouping feature has become a false-positive multiplier.

The practical job is to use the fingerprint where grouping helps, then make the decision from the route, behaviour and consequence. This article sets out one way to do that.

Start with the route, not the fingerprint

A request for a cached image and a request to submit a password do not deserve the same policy. Neither do a search request and an export that starts an expensive database job.

Before adding fingerprint data, classify the routes that matter:

what the request can change or disclose;
whether it consumes scarce application or origin capacity;
whether a legitimate user can retry safely;
whether the client can complete a challenge;
which identity is available, such as an account, session, API key or no identity at all;
what an incorrect block would cost.

This route map sets the response. An unfamiliar cohort fetching public content might only be worth observing. The same cohort attempting passwords across many accounts may justify a tight shared limit. A fingerprint mismatch on an authenticated payment action may call for step-up verification rather than a network block.

Route sensitivity also prevents a common emergency mistake: applying a site-wide rule because an attack was visible on one endpoint. Narrow rules are easier to explain, test and remove.

Use the fingerprint as a cohort key

JA3, JA4 and Cisco Mercury do not identify a person or device. Each method selects and normalises protocol fields, then groups connections that look equivalent under those rules. Our same-ClientHello lab shows how three methods produce three different representations from one handshake.

That makes the fingerprint useful for questions such as:

Are login failures arriving from many IP addresses but one narrow set of client stacks?
Did an expensive API route suddenly attract a new protocol cohort?
Does traffic claiming to be a browser have a consistent TLS, HTTP and header shape?
Did a cohort disappear after an abusive tool changed version, or did the fingerprinting rules change underneath us?

The key should be composite. A workable rate counter might resemble:

route_class + fingerprint_method + fingerprint_version + fingerprint_value

Depending on the abuse case, add an account, tenant, API credential, ASN or country. Do not throw every field into every key. An over-specific key divides a distributed campaign into buckets too small to see; an over-broad key combines unrelated users.

Run a few candidate keys in observation mode and measure their bucket sizes. Look at both tails. A key that places half the site's users in one bucket is too blunt for direct enforcement, however suspicious that bucket looked during one incident.

Record where the value came from

Fingerprint provenance is operational data, not documentation trivia.

At an origin behind a CDN or reverse proxy, the visible TLS connection may belong to that intermediary. A fingerprint forwarded in a header might describe the original client-facing connection, or it might describe a later hop. The receiving service cannot tell from the hash alone.

For each event, keep at least:

method:       ja4
version:      pinned implementation or rule version
value:        t13d..._..._...
capture:      client-facing edge
source:       named collector or trusted forwarding hop
observed_at:  timestamp
policy:       policy identifier and revision
action:       observe, challenge, rate-limit or block

Where the format permits it, retaining the selected raw fields or unhashed representation makes later comparison much easier. Cisco Mercury's full Network Protocol Fingerprint is structured and versioned; its optional hash is a compact nickname that discards that structure. JA4 publishes both a canonical hashed form and a raw JA4_r form. The details are in the Mercury NPF specification and JA4 technical specification.

Trust the forwarding path as deliberately as any other security metadata. Strip client-supplied copies at the boundary, set the authoritative value there, and record the hop that produced it. Otherwise an attacker may be able to choose the value used by the policy.

Use an action ladder

Bot controls work better with space between “allow” and “block”. A simple ladder is observe, challenge, rate limit, then block. It is not a mandatory sequence for every request; it is a way to match disruption to confidence.

Observe

Observation is the right first action for a new cohort, a changed implementation or a weak hypothesis. Record volume, routes, account outcomes, response codes, request cost and how the cohort overlaps with known legitimate clients.

Set an end date before starting. “Log this for seven days and review on Monday” produces a decision. “Log this” often produces another permanent stream nobody owns.

Challenge

A challenge asks the client for more evidence. It can separate some interactive browsers from simple automation, but it is not a universal test of humanity. Browser automation can complete challenges; privacy software, accessibility tools and broken JavaScript can make legitimate users fail them.

Use challenges where the client can reasonably complete one and where failure has a safe recovery path. They are a poor fit for machine-to-machine APIs unless the protocol already defines an authentication or proof step.

Rate limit

Rate limiting fits repeated or costly behaviour. Count a cohort against the route it is affecting, then layer in the identities that make sense for that route. For example:

login:  fingerprint + account + failed outcome
search: fingerprint + route + request cost
API:    fingerprint + tenant or credential + operation

A limit should say what it protects. Requests per minute is sometimes enough. Expensive operations may need a cost-weighted budget. Login protection may count failed attempts while allowing successful account recovery to proceed. Distributed abuse may need a cohort-wide ceiling plus per-account and per-IP limits so that no single key carries the whole policy.

Return an explicit response and keep the retry behaviour predictable. The HTTP 429 Too Many Requests status was defined for rate limiting in RFC 6585, including the option to send Retry-After. Clients still need sensible backoff, and operators need to watch whether retries are making origin pressure worse.

Block

Block when the evidence is strong, the harm is current, and a less disruptive action cannot protect the route. Good candidates include a confirmed exploit tool hitting the vulnerable route, a cohort causing active availability loss, or repeated abuse that has failed narrower controls.

Keep the scope bounded: fingerprint method and version, affected route, relevant behaviour, start time, owner and expiry. A bare fingerprint deny-list with no incident context is hard to audit and tends to outlive its evidence.

For a broader mapping of actions to evidence, see Network Fingerprint Signals and Security Decisions and Network Fingerprinting for Rate Limiting.

Combine evidence before increasing friction

The most useful policy does not ask whether a fingerprint is good or bad. It asks whether several observations agree.

Consider a login campaign. The source addresses rotate through residential networks. The TLS cohort is common because the tool drives a real browser. The fingerprint alone is weak. But the same traffic may attempt many accounts, reuse a route sequence, fail at a high rate, omit normal session history and arrive at a cadence unlike ordinary users. Together those observations justify a shared limit or challenge.

Now reverse the example. A rare TLS cohort signs in successfully to one account from its usual region, follows a normal route sequence and maintains an established session. Rarity does not add much. Blocking it would mostly punish an unusual client.

This is also the line between a format and a detection system. JA4 defines a fingerprint. Mercury defines fingerprint representations and includes separate analysis components. Any claim such as “this is Chrome”, “this is a scraper” or “this is malicious” comes from surrounding data and inference, not from the fingerprint characters themselves. A Network Fingerprint Is a Cohort, Not a Client explains that boundary in more detail. Fingerprints Are Evidence, Not Identity covers the same problem across browser, network and behavioural fingerprints.

Expect versions and populations to drift

Browsers ship, TLS libraries change defaults, mobile applications update unevenly and attack tools copy popular handshakes. Fingerprint implementations also change their parsing rules. Store the method and implementation version so client drift can be separated from detector drift.

Before changing an implementation, calculate old and new values side by side on a sample. Compare cohort sizes and known-good traffic by route. A partner API, mobile application and public website have different expected populations; a global label may be irrelevant to the local control.

Put expiry and rollback in the policy

Every enforcement rule needs an owner, reason, expiry and removal condition. Before enabling it, record request volume, successful transactions, challenges, 429 responses and origin health. Compare the same measures afterwards. A falling attack rate is not success if legitimate completion falls with it.

When a false positive appears, retain the fingerprint version, capture point, contributing evidence, route, identity, policy revision and rollback result. That record shows whether to change a threshold, split a route class, add an exception, demote the action or remove the fingerprint from the key.

A deployable first policy

For a first production use, choose one abused route. Generate a versioned fingerprint at a trusted capture point, log it beside the route and outcome, and observe cohort sizes long enough to include normal variation. Then choose one reversible action with success measures, rollback and an expiry.

The fingerprint has done its job when it helps a team see and control a group of requests that an IP-only rule would miss. It has exceeded its job when the group is treated as proof of a client, person or intent.

One ClientHello, Three Fingerprints: JA3, JA4 and Mercury

2026-07-12T09:00:00+10:00

The easiest way to misunderstand network fingerprints is to compare example strings taken from different clients. We wanted a cleaner test: one packet capture, one TLS ClientHello and three fingerprint formats.

The complete lab is checked into this site's source under labs/network-fingerprinting/, and the publication bundle is available here. It pins the tool revisions, reconstructs the fixture, verifies its checksum, runs the tools and checks that their outputs refer to the same connection. Nothing in the comparison depends on a vendor database or an application label.

The input

The fixture is a 329-byte Peakhour-generated capture containing a local OpenSSL 3.5.6 ClientHello wrapped in one synthetic Ethernet/IPv4/TCP packet:

10.1.1.1:40000 -> 10.2.2.2:443
SNI: lab.peakhour.test

The lab stores the small fixture as base64 under an adjacent BSD 3-Clause licence and verifies the decoded PCAP with SHA-256 before using it. The reserved SNI and private addresses did not cross a network. We select packet 1 and TCP stream 0. That selection matters: saying that several tools read the same PCAP is weaker than proving that their output describes the same flow and ClientHello.

The pinned revisions for this run are:

Cisco Mercury  3172786645f70e1a8347d8cf020b736e185651e5
FoxIO JA4      0e54bc8371de34df94a35f2442c05bda2e8b2034
Salesforce JA3 502cc6395811c54743b0561419d61900a6df3ff7

These pins are part of the result. Fingerprint implementations and specifications change. A value without its method and version is harder to reproduce than it first appears.

Running the lab

From the repository root:

./labs/network-fingerprinting/run.sh
python labs/network-fingerprinting/verify.py

The runner fetches the pinned source archives, builds or invokes the implementations in a temporary work directory, and writes evidence to labs/network-fingerprinting/results/. The verifier checks the fixture and output checksums, connection tuple, SNI and output shape. The pinned source URLs are enforced by the runner rather than inferred by the verifier.

This is a fingerprint-format lab, not a speed test. Build time, runtime and memory use depend heavily on language, wrapper and capture path, so we do not compare them here.

JA3: a portable exact-match digest

For this ClientHello, the canonical JA3 feature string is:

771,49196-49200-159-52393-52392-52394-49195-49199-158-49188-49192-107-49187-49191-103-49162-49172-57-49161-49171-51-157-156-61-60-53-47,65281-0-11-10-35-16-22-23-13,29-23-30-24-25,0-1-2

Its MD5 digest is:

e1934f32e97b0bd52227953ca7d30118

The digest is convenient for logs and exact lookup. On its own it does not show which cipher, extension or group changed. The pre-hash string retains enough information to investigate that difference, which is why throwing it away too early can make later analysis harder.

JA3 removes GREASE values but otherwise retains the order of its selected lists. A client that permutes extension order can therefore generate a new JA3 digest without changing its effective TLS capabilities. The archived Salesforce JA3 repository defines the input fields and GREASE handling.

JA4: canonicalised components

The same ClientHello produces this JA4:

t12d2709h2_a2460661a67a_36cef8aed422

Its first section is readable:

t means TLS over TCP;
12 is the highest supported TLS version after ignoring GREASE;
d says a domain was present in SNI;
27 and 09 are the cipher and extension counts after the format's exclusions;
h2 summarises the first ALPN value.

The second section is the first 12 hexadecimal characters of SHA-256 over sorted cipher identifiers. The third is a truncated SHA-256 value derived from sorted extension identifiers and the signature algorithms in their original order. The canonical JA4 technical specification defines the exact exclusions and encodings.

The lab also records JA4_r, the raw form used by the FoxIO tooling:

t12d2709h2_002f,0033,0035,0039,003c,003d,0067,006b,009c,009d,009e,009f,c009,c00a,c013,c014,c023,c024,c027,c028,c02b,c02c,c02f,c030,cca8,cca9,ccaa_000a,000b,000d,0016,0017,0023,ff01_0403,0503,0603,0807,0808,0809,080a,080b,0804,0805,0806,0401,0501,0601,0303,0301,0302,0402,0502,0602

That makes the normalisation visible. It also shows why JA4 is not fuzzy hashing: sorting makes selected permutations equivalent, while the hashes still support equality matching rather than semantic distance.

Mercury NPF: a retained protocol tree

Cisco Mercury 2.18 emits this tls/2 fingerprint for the same ClientHello:

tls/2/(0303)(c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f)[(0000)(000a000c000a001d0017001e00180019)(000b000403000102)(000d002a0028040305030603080708080809080a080b080408050806040105010601030303010302040205020602)(0010000e000c02683208687474702f312e31)(0016)(0017)(ff01)]

The value is longer because it is doing another job. Parentheses and square brackets describe an ordered tree of selected byte strings. In the draft NPF notation, square brackets mark a lexicographically sorted list. The tls/2 prefix names the protocol and fingerprint rule version.

An analyst can inspect the retained values rather than relying only on a digest. Mercury also defines a compact hash nickname when a fixed-length index is needed, but that nickname loses the structure used for inspection, prefix comparison or approximate matching. Cisco's draft NPF specification documents both representations.

The Mercury JSON includes the same source and destination tuple and the same SNI as the JA3 and JA4 records. It does not identify the client application in this lab because we did not run a labelled fingerprint knowledge base or the destination-context classifier. A packet-derived NPF value and a process assessment are separate outputs.

What the comparison establishes

All three methods observe the same ClientHello, but they define similarity differently.

Question	JA3	JA4	Mercury NPF `tls/2`
Compact default	Yes	Yes	No; optional hash available
Inspectable selected inputs	Only if the pre-hash string is retained	Partly in `a`; fully in the recorded raw form	Yes in the full tree
Selected list sorting	No, after GREASE removal	Ciphers and most extensions	Rule-specific selected extensions
Explicit format version in value	No	Encoded field semantics, but no separate rule number	Yes
Semantic or approximate comparison	Not from the digest	Component grouping, not hash distance	Full structure can support richer matching
Application attribution in the format	No	No	No

The table does not produce a universal winner. JA3 remains useful where historical compatibility matters. JA4 is compact and handles selected permutations cleanly. Mercury retains more material for inspection and for analysis systems that need structured features.

It also shows what none of the values can establish. The capture does not prove which person, device or application created the connection. Shared libraries, browser impersonation and software updates all complicate that inference. See A network fingerprint is a cohort, not a client for the operational consequences.

For the history behind these design choices, read Two lineages of TLS fingerprinting. The durable format comparison is in Mercury vs JA4 vs JA3.

How to fix your Adobe Commerce Overages with Fastly

2026-07-01T08:13:00+10:00

Adobe Commerce merchants do not usually notice Fastly overages straight away.

Traffic looks normal. Revenue looks normal. The site feels fine. Then the bill lands and CDN usage is well above contract.

In our experience, the drivers of CDN overages are due to Adobe Commerce and Fastly default behaviour.

The biggest culprits are:

shielding
ESI forcing uncompressed HTML from origin
PNG-heavy catalogues and storefront assets
bot traffic pouring fuel on all of the above

We recently worked with Dymocks and helped them reduce their CDN usage from 55 TB of monthly traffic down to 6 TB after we fixed the waste in the delivery path and filtered unwanted traffic, case study coming soon.

1. Shielding helps performance, but it can hurt your bill

Fastly shielding exists for a good reason. It reduces origin load and can improve cache efficiency by funnelling misses through a shield POP before they go back to origin.

The catch is billing.

Fastly is clear that traffic from one POP to another counts towards both request count and billable bandwidth. In the most extreme case, if everything is effectively a pass, request count and delivery bandwidth can almost double because the request is handled by two Fastly POPs instead of one.

That means a cache miss is no longer a simple edge-to-origin event. It becomes:

edge → shield → origin → shield → edge

If your cache hit rate is strong, that trade-off may still be worth it. If page caching is weak, purges are frequent, or large parts of the site are missing cache, shielding turns into a billing multiplier.

2. ESI (Edge Side Includes)

ESI is an old technology that allows a proxy (like Fastly) to 'assemble' pages using content fetched from another source.

Adobe Commerce/Magento 2 will use ESI out of the box for its navigation bar. The reasoning is to allow the navigation to be purged from the CDN independent of the page content. In theory this makes Full Page Caching more effective. In practise the difference is negligible as the Full Page Cache is cleared daily anyway.

Fastly’s ESI documentation says ESI cannot be performed on content compressed at origin. Fastly needs to inspect the response body for <esi:...> tags, and compressed content hides those tags from the parser.

The default Fastly configuration for Adobe Commerce will strip the client Accept-Encoding header before the request goes to origin.

The origin then returns uncompressed HTML, Fastly scans it for ESI, and only later is the response compressed again at the EDGE before it is delivered to the browser.

From the shopper’s point of view, nothing looks wrong. The page still arrives compressed at the edge. Performance may still look fine.

From a billing point of view, it is a very different story.

Magento’s default layout gives the top navigation block a ttl="3600" in default.xml, which makes it an ESI candidate out of the box. The Fastly Magento VCL snippets also show the downstream effect: Fastly sets x-compress-hint because “varnish doesn't compress ESIs”, so compression is pushed later in the chain.

Now combine that with shielding.

Say your page is:

50 KB compressed
600 KB uncompressed

If the request misses cache and shielding is enabled, you are not paying for a tidy 50 KB response. You are moving the 600 KB object through the shield path, and that larger object is counted across both the shield and edge legs.

That is effectively a 600 KB × 2 event.

That is why broken page caching hurts twice:

you get more misses
each miss is much larger than most teams realise

If enough HTML is missing cache, overages rise very fast.

3. A simple way to spot the problem in New Relic

An easy way to check for ESI driven egress is to open New Relic and look at CDN usage by content type.

If text/html is driving more usage than images, that is a strong sign you are paying for uncompressed page responses on cache misses.

text/html content type being the top CDN usage content type is a red flag.

That pattern usually points back to the same combination:

ESI
shielding
weak cache hit rates

On a healthy eCommerce site, images are usually the major share of bandwidth. When HTML starts dominating, something is off.

4. PNGs are another quiet cost driver

Fastly can absolutely turn a PNG into WebP, but that does not automatically mean you get a small lossy image.

Fastly’s own Image Optimizer reference says that if the source image is a lossless format, the output defaults to lossless when the chosen output format supports it. Fastly is explicit about the PNG case: with a PNG source and format=webp, format=jxl, or format=auto, the output image is lossless by default. In other words, Fastly can transform a PNG into a lossless WebP unless you explicitly force a lossy path.

That is why PNG-heavy catalogues can still burn a lot of bandwidth even when teams think Fastly is “optimising” them. The image format may change, but the delivery path can still stay lossless, which means the file is often much larger than expected. Fastly also notes that lossless output preserves all image data and therefore produces larger file sizes, basically the same as the source image.

This is where many Adobe Commerce stores get caught out. Most merchants rely on the default Fastly image setup and do not add per-image parameters or rewrites. Fastly’s documentation says that most image transformations require query string parameters on individual requests, and its default behaviour notes that WebP quality is 85 for lossy WebP images, not that every PNG source is automatically pushed into lossy Webp.

If you want smaller files, you need to force the outcome. Fastly says you can do that by using format=auto with quality<100, or by explicitly using a lossy WebP path. Adobe Commerce’s Fastly image optimisation settings also expose a Force lossy conversion option for this reason.

What to do about it

You do not need a full replatform to reduce overages. Most of the wins come from cleaning up the delivery path.

Review shielding

Start by measuring shielding, not assuming it is free.

Disabling shielding can be a fast way to cut billable traffic. The trade-off is lower cache efficiency and more origin load, so this needs testing, not guesswork.

Remove ESI where it is not earning its keep

On many Adobe Commerce builds, ESI is there mainly so the navigation block can be flushed independently.

That is rarely a good reason to pay for inflated HTML misses.

The usual fix is:

change the Magento layout or template so the block no longer needs ESI
strip the X-ESI path in VCL
restore Accept-Encoding to origin requests so HTML can travel compressed again

This is often the biggest bandwidth win because it reduces the size of every miss, not just edge delivery.

The immediate effect of disabling ESI and enabling compression from origin.

Force lossy png conversions

Fortunately forcing lossy conversion of PNG images is relatively straightforward.

Use VCL to rewrite image urls to include a query string, eg

    /someimage.png

becomes

    /someimage.png?format=auto&quality=85

Expect a 400kb source image to go to 100kb for no discernable difference. Play with quality for bigger gains.

Do not ignore bots

Then there is the traffic you never wanted in the first place.

Bad bots amplify every weakness above. They hit uncached pages, search pages, category pages, and dynamic endpoints. That creates more misses, more uncompressed HTML fetches, more shield traffic, and more wasted bandwidth.

This is why CDN cost control is not just a caching conversation. It is also a traffic quality conversation.

If you can stop junk traffic before it burns CDN bandwidth, the savings stack on top of the caching fixes.

That is where Peakhour fits. We help stores cut unwanted bot traffic before it turns into Fastly overages, and the upside can be dramatic. For example, we've helped one store go from 55 TB per month down to 6 TB.

Final thought

If your Fastly bill feels out of proportion to real shopper demand, start with two questions:

Why are we missing cache so often?
Why is text/html using so much bandwidth?

If those numbers look wrong, the overage usually stops being mysterious.

Edge Security is now a Privacy Compliance Issue

2026-06-25T08:13:00+10:00

For Australian businesses, website security is no longer just an IT problem. If a website collects, processes or exposes personal information, edge security is now part of privacy compliance.

That shift matters because many organisations still treat cyber compliance as an Essential Eight exercise. They focus on patching, MFA, backups, restricted administrative privileges and endpoint hardening. Those controls are important, but they do not fully protect the public-facing web applications, APIs, customer portals and login flows where personal information is often exposed.

Under Australian Privacy Principle 11 — security of personal information, an APP entity that holds personal information must take reasonable steps to protect it from misuse, interference, loss, unauthorised access, unauthorised modification and unauthorised disclosure. The Act also makes clear that those steps include technical and organisational measures.

That wording is important. It means privacy compliance is not limited to policies, contracts and internal IT controls. If customer data is reachable through a website or API, then the controls protecting that website or API become part of the privacy compliance story.

Essential Eight is the floor, not the whole building

The Essential Eight is a valuable baseline. The ACSC says it makes it much harder for adversaries to compromise systems, while also noting that no set of mitigation strategies can protect against all cyber threats.

That distinction is important for web applications.

A business can be mature against Essential Eight and still leave its public-facing website exposed. It may have MFA for staff, but no effective protection against credential stuffing on customer accounts. It may patch internal systems, but still allow bots to abuse login, checkout, account, booking or password reset endpoints. It may have backups, but no useful web-layer logs to understand whether personal information was accessed.

Essential Eight helps reduce compromise risk across the corporate environment. Edge security helps protect the application layer where customers, bots, attackers and APIs interact in real time.

For any business that handles personal information online, both are needed.

The edge is where privacy risk often appears first

Most attacks against websites do not start with malware on an employee laptop. They start with HTTP requests.

Attackers test login forms with leaked credentials. They scrape customer portals. They abuse APIs. They enumerate accounts. They probe CMS plugins. They bypass exposed origins. They overload search, checkout or booking endpoints. They automate password reset flows. They use residential proxies and headless browsers to make malicious traffic look like normal customer activity.

From a privacy perspective, this matters because these attacks can lead directly to unauthorised access, disclosure, misuse or loss of personal information.

That is exactly the risk APP 11 is concerned with.

If a website exposes customer names, addresses, order history, invoices, loyalty balances, support tickets, identity documents, health information, student records or account data, the edge is part of the control environment. It is the place where malicious traffic can be blocked, challenged, rate limited, logged or allowed through to the origin.

Government guidance points beyond basic IT hygiene

The ACSC’s guidance on securing customer personal data recommends practical controls such as creating a register of personal data, limiting what is collected, deleting unused data, controlling access, encrypting data, backing it up, and logging and monitoring access.

For a website, those recommendations have direct edge and application-layer implications.

A register of personal data should include not only databases, but also web forms, APIs, CDN logs, application logs, analytics tools, third-party scripts, support systems and staging environments. Limiting collection should mean removing unnecessary fields from forms, avoiding personal information in URLs, and not sending sensitive data into analytics or debugging tools without a clear reason. Logging and monitoring should include requests to sensitive endpoints, not just server health metrics.

In other words, practical privacy protection has to reach the web stack.

WAF, rate limiting and bot management are privacy controls

A web application firewall is often seen as a security control. Rate limiting is often seen as an availability control. Bot management is often seen as a cost or performance control.

For websites handling personal information, all three are also privacy controls.

A WAF helps block common exploit attempts before they reach the application. Rate limiting helps reduce brute force attacks, account enumeration, password reset abuse, checkout abuse and application-layer denial of service. Bot management helps identify credential stuffing tools, scrapers, automation frameworks, fake browsers and proxy-based abuse.

These controls do not replace secure application development, access control or data minimisation. But they reduce the chance that personal information can be accessed or harvested through normal-looking web requests.

That matters because many privacy incidents are not sophisticated intrusions. They are automated abuse at scale.

A login form without bot protection can become a credential stuffing endpoint. A search API without rate limits can become a scraping interface. A customer portal without behavioural monitoring can become a data extraction tool. An exposed origin can bypass the very controls the business thought were protecting the site.

Edge logging supports breach assessment

Privacy compliance is not only about preventing incidents. It is also about understanding them.

When something goes wrong, a business needs to answer practical questions. Which accounts, IPs, sessions or API keys accessed the affected records? Which endpoints were used? Was the traffic automated? Did it come through the CDN or bypass it? Was the data viewed, modified or exported? What personal information may have been exposed?

Without edge and application-layer logs, those questions are hard to answer.

That creates a second-order privacy problem. If a business cannot determine what happened, it may struggle to assess the seriousness of an incident, notify accurately, or explain what remedial action was taken.

Good logging does not mean storing personal information in logs forever. It means capturing enough security metadata to reconstruct access patterns while avoiding unnecessary personal information in the logs themselves.

Data minimisation also applies at the edge

Privacy risk increases when personal information spreads through systems that were never designed to store it.

Websites often leak personal information into places businesses forget to review: query strings, CDN logs, analytics events, error traces, session replay tools, marketing pixels, staging databases, CSV exports and support tickets.

That is why data minimisation should apply to the whole request path, not only the production database.

Do not put personal information in URLs if it will be logged by browsers, proxies, CDNs and analytics tools. Do not send unnecessary personal information to third-party scripts. Do not retain verbose request logs longer than needed. Do not copy production customer data into staging unless there is a controlled and documented reason. Do not collect fields “just in case”.

The less personal information that passes through the edge, the less there is to expose, protect, delete and explain.

What this means in practice

For Australian websites handling personal information, edge security should now be treated as part of the privacy control set. That usually means:

placing the site behind a CDN or edge security layer
enabling WAF protection for common application attacks
applying rate limits to login, registration, password reset, checkout, search and API endpoints
using bot management to detect scraping, credential stuffing and automated abuse
locking down the origin so attackers cannot bypass edge controls
logging enough request metadata to support investigation and breach assessment
reviewing what personal information appears in URLs, headers, cookies, logs and analytics
applying retention and deletion rules to CDN logs, application logs and third-party tools

The important point is not that every website needs the same controls. A simple contact form does not create the same risk as an ecommerce account portal or health booking system. The point is that the controls should match the risk created by the personal information being handled.

That is the practical meaning of “reasonable steps”.

The takeaway

Edge security has moved from being a performance and availability issue to being a privacy compliance issue.

For Australian businesses, Essential Eight remains a sensible baseline. But it does not prove that a public-facing website, API or customer portal is protected against the most common ways personal information is abused online.

If personal information is collected, accessed or processed through the web application, then WAF, bot management, rate limiting, origin protection, API controls, logging and data minimisation all become part of the privacy compliance conversation.

The question is no longer just whether the business has implemented Essential Eight.

The better question is: if an attacker came through the front door of the website, could the business show it had taken reasonable technical steps to protect the personal information behind it?

An Operating Model for API and Account Protection

2026-06-19T00:00:00+10:00

API and account protection is often discussed as a stack of controls: authentication, MFA, bot detection, rate limiting, WAF rules, logging, fraud checks, and incident response. Those controls matter, but the missing piece is usually the operating model.

Who owns the route? Which signals are trusted? What action should happen before origin? What evidence is preserved? When does a rule move from monitor to enforce? How does the team know whether it helped or hurt?

Without those answers, account protection becomes a set of disconnected gates. The login page has one policy. The mobile API has another. Password reset is reviewed only after support tickets appear. Rate limits are tuned during incidents, then left in place because nobody wants to touch them.

A better model is route first, signal second, action third, evidence always.

1. Map the Routes That Matter

Start with the account and API routes that change trust, money, access, or user state. Do not begin with every endpoint in the estate. Begin with the flows where abuse has a clear consequence.

Typical routes include:

Login and token issue.
Token refresh.
Password reset start and completion.
MFA enrolment and recovery.
New account registration.
Email, phone, address, and password changes.
Stored payment, wallet, loyalty, or checkout actions.
High-volume read APIs.
Partner or machine-to-machine API access.

For each route, record the owner, normal traffic shape, expected clients, authentication method, downstream cost, and likely abuse case. A login endpoint and a product search endpoint can both be APIs, but they should not have the same policy.

This is where traffic control becomes part of account security. The route tells the edge what kind of decision is being made: allow, challenge, throttle, block, route, cache, or log.

2. Classify the Signals Before Choosing the Action

A useful account decision combines several signal families:

Identity and token state.
Credential exposure or failed-login history.
Residential proxy, VPN, hosting, mobile, or office network context.
IP reputation and ASN behaviour.
Client, browser, TLS, or HTTP fingerprint.
Request rate and response codes.
Route sequence and session behaviour.
Account event context, such as reset, recovery, or profile change.

The mistake is treating any one signal as the whole answer. A residential proxy signal on a low-risk route may only need monitoring. The same signal on a password reset route, with repeated failures and a first-seen client, should be handled differently.

This is the job of contextual security: apply friction where the request context justifies it, while keeping trusted users on the shortest path.

3. Choose Actions That Match Route Risk

Not every suspicious request should be blocked. Blocking is one action, and it should be available, but account protection needs a wider set of responses.

Common actions include:

Allow and record.
Log only.
Add to a rate-limit zone.
Throttle or return a 429.
Require a challenge.
Require step-up authentication.
Deny the request.
Route to a safer path.
Alert security or support.

Advanced rate limiting is useful here because the counter does not have to be the source IP. For API traffic, a policy may key on an Authorization header, token, fingerprint, route, cookie, response code, or a combination of fields. For account flows, response-aware limits can count failed logins or suspicious reset attempts, then apply a stricter rule on the next request.

This matters for distributed abuse. If attackers rotate through residential proxies, a simple IP counter sees fragments. A route-aware, signal-aware policy can still recognise the behaviour that matters.

4. Preserve Evidence While the Control Runs

A security decision that cannot be explained will be difficult to tune and harder to defend internally. Teams need to know why a request was allowed, challenged, throttled, or blocked.

The evidence should keep the request, route, signal, policy, action, and outcome together. That includes useful fields such as the matched route, rate-limit zone, proxy or IP classification, fingerprint, response code, decision reason, and timestamp.

Log forwarding is part of the operating model, not an afterthought. If the evidence only exists in a dashboard screenshot or a short-lived edge event, support, fraud, platform, and security teams will end up reconstructing incidents by hand. Forwarded logs should carry enough context into the SIEM, object store, or observability pipeline for investigation and tuning.

This also protects the rollout. When a control is in monitor mode, evidence shows who would have been affected. When it is enforced, evidence shows who was affected and why.

5. Tune From Monitor to Enforce

The safest way to deploy account and API controls is usually staged:

Monitor the route and collect baseline evidence.
Add low-friction actions, such as logging or soft thresholds.
Review false positives, support impact, and route ownership.
Enforce on the clearest abuse patterns.
Expand enforcement only where evidence supports it.
Keep rollback and emergency tightening paths documented.

This avoids two common failures. The first is leaving controls in monitor mode forever because nobody owns the decision to enforce. The second is enforcing too broadly and creating customer friction that causes the business to bypass the control.

A staged model gives security, platform, product, and support teams a shared language. The rule is not "on" or "off". It has a route, a risk case, an action, evidence, and a review cycle.

6. Fit the Model to the Edge You Already Run

Some teams want Peakhour as the active application edge. Others need to keep Cloudflare, Fastly, CloudFront, another CDN, or an existing hosting edge in place. That deployment choice should not change the operating principle.

The goal is still to classify request context before origin, apply the right action, and preserve evidence. Bring Your Own Edge matters because many organisations cannot redesign delivery just to improve account protection. They need a control path that fits the architecture they already operate.

The practical test is straightforward: can the team explain what happened to a sensitive account or API request without guessing?

If the answer is no, the next step is not another generic control. It is an operating model: map the route, classify the signals, choose the action, preserve the evidence, and tune the policy from observed behaviour.

That is how API and account protection becomes something the organisation can run, not just something it bought.

API Bot Abuse Does Not Stay in One Endpoint

2026-06-19T00:00:00+10:00

API bot abuse rarely stays politely inside one endpoint.

A campaign may start at login, move through token refresh, test account recovery, check saved addresses, probe checkout, abuse coupons, scrape product availability, and then return to account actions once a working session is found. Looking at each route alone makes the activity seem smaller than it is.

The pattern matters more than the individual request.

That is why API bot protection has to follow journeys, not just endpoints.

Login Is the First Measurement Point

Login endpoints are the obvious place to look for bot abuse. Credential stuffing, password spraying, brute force attempts, and token abuse all show up there.

But the login endpoint is only the first measurement point. Attackers are not trying to create a failed-login graph. They are trying to find usable accounts and move to the next action.

A bot campaign may keep failed attempts low per IP address. It may rotate through residential proxies. It may slow down to avoid simple thresholds. It may mimic the browser request shape closely enough to get past a basic check. It may use an API route that exists for the mobile app rather than the public login form.

So the useful question is not just "how many login attempts did we see?" It is "which client, route, network, fingerprint, account, and response pattern suggests automation?"

That is where bot management belongs in the account journey. It should not be an isolated "human or bot" label. It should become part of the request evidence used for login, recovery, checkout, and account-change decisions.

Checkout Abuse Is Often API Abuse

Checkout abuse is not always a stolen-card problem. It can be a request-path problem.

Bots can test coupon codes, reserve inventory, create carts, check delivery combinations, retry payment flows, and exploit business logic at machine speed. Some of this happens through visible browser journeys. Much of it happens through APIs used by the front end or mobile app.

The damage is not always dramatic in a single request. A few extra cart creations may look normal. A small number of coupon checks may be expected. A payment retry can be legitimate. The problem is the campaign shape across routes.

If the same automation profile moves through login, cart, promo, shipping, and payment APIs with abnormal timing or sequencing, the response should not depend on one endpoint crossing a crude global limit.

It should be route-aware.

A checkout API can tolerate different behaviour from a catalogue API. A payment route deserves different thresholds from a product search route. A coupon route may need controls around account age, session state, rate, and client evidence. A cart route may be harmless in one context and abusive in another.

Account Journeys Need Sensitive-Action Controls

Account abuse becomes most damaging when a session moves into sensitive actions.

Changing an email address, resetting a password, adding a new delivery address, viewing stored payment details, redeeming loyalty value, or placing an order are different from normal browsing. They deserve stronger context.

The request may be technically valid. The token may pass validation. The password may be correct. The API schema may be satisfied. That does not mean the action is safe.

A strong control model looks at the full path into that action. Did the session begin with credential stuffing signals? Is the client first seen? Did the network change? Is there proxy or fingerprint drift? Has the account recently failed login attempts? Is the request cadence consistent with a human journey? Is the action unusually soon after authentication?

These are not abstract "zero trust" slogans. They are practical checks on the account request path.

Rate Limits Need Better Keys

API abuse prevention often starts with rate limiting, but IP-only limits struggle with distributed automation and shared networks. The hard part is deciding what to count.

For API bot abuse, useful rate keys can include route, method, account, token, API key, response code, ASN, country, TLS or HTTP fingerprint, verified bot state, and combinations of headers. The right key depends on the journey.

A login endpoint might count failed attempts by account and fingerprint. A token endpoint might count refresh patterns by client and session. A checkout route might count attempts by account, payment state, and client fingerprint. A partner API might count by API key and route.

Advanced rate limiting is valuable because it can model the abusive actor more precisely than a single IP address. It also gives teams response options short of blanket blocking: log, challenge, throttle, or deny depending on the route and risk.

That matters because real API traffic includes customers, mobile apps, partners, service clients, good bots, bad bots, and increasingly AI-driven agents.

Agents Will Make the Journey Problem Harder

The next wave of automated API use will not all look like simple scripts. As discussed in Agentic AI vs. Your API, reasoning agents can explore, adapt, and change their behaviour based on responses.

That does not mean every AI agent is malicious. It does mean endpoint-by-endpoint rules will age quickly.

A reasoning agent can try one path, observe the result, and adjust. It can move from documentation to browser-backed APIs to mobile-shaped requests. It can test which routes are protected, which errors reveal state, and which actions trigger stronger checks.

Defence needs the same journey view. The campaign should be visible as it moves, even when the exact request pattern changes.

Keep Evidence Attached to the Campaign

API bot abuse is easier to manage when the evidence stays attached.

The useful record is not just "blocked by rule 42". It is the route, account state, token or key context, fingerprint, proxy signal, rate key, response pattern, action taken, and protected business step. That evidence lets teams tune controls without guessing and investigate incidents without reconstructing the whole path from raw logs.

For broader background, API abuse prevention covers the categories. The operational point is narrower: login, checkout, and account APIs should not be defended as separate islands.

Attackers use the journey.

The defence should too.

API Protection and Account Protection Are One Request-Path Problem

2026-06-19T00:00:00+10:00

Account protection is often discussed as if it belongs to the login page. That made sense when most account abuse looked like someone submitting a username and password into a web form.

That is not how modern account journeys work.

A customer signs in through a browser, a mobile app, a partner integration, a password reset flow, a token refresh endpoint, a profile update request, a checkout API, and sometimes a service-to-service call that exists nowhere in the visible front end. The account is not protected by one screen. It is protected, or exposed, by the whole request path.

That is why API security and account protection should not be treated as separate operating problems. The API route, the identity context, the client evidence, the rate pattern, the token behaviour, the bot signal, and the account action all arrive together. Splitting those signals across disconnected tools makes the final decision weaker.

The Login Is Only the Start

Credential stuffing is the obvious example. Attackers test leaked credentials against login endpoints, but the useful outcome is rarely the login itself. The value comes after the session opens.

They try to change the email address. They add a shipping address. They reset a password. They check stored cards. They redeem loyalty value. They place an order. They call account APIs that were built for the real customer journey and then abuse them in a different sequence.

If the login defence is separate from the API defence, the organisation may see only fragments:

A spike in failed logins in one dashboard.
A suspicious token refresh pattern somewhere else.
A burst of profile-change requests in application logs.
A fraud case after checkout.

Each of those is useful. None is the full story.

The better model is to keep the decision close to the request. A request to /login is different from a request to /account/email, /checkout/payment, or /api/token/refresh. The route matters. So does the method, the session state, the previous failures, the network, the client evidence, and the account action being attempted.

APIs Carry Account Risk

APIs are not just developer plumbing. They are where many account journeys now happen.

Mobile apps use APIs for login, registration, password reset, saved addresses, payment methods, and checkout. Single-page applications call APIs behind browser journeys. Partner systems may call account or order APIs directly. Internal services may use API keys or service credentials that function like non-human accounts.

That creates a practical issue: account protection must cover both human and non-human identity paths.

OAuth, JWTs, API keys, refresh tokens, and service credentials all need lifecycle control, least-privilege access, rotation, validation, and monitoring. But those controls are still not enough if the protected API cannot see whether the request is behaving like abuse.

A valid token can be stolen. A valid API key can be overused. A real session can be driven by automation. A known customer can suddenly perform a high-risk action from a first-seen client through proxy infrastructure.

The request has to be judged in context.

Rate Limiting Has to Follow Business Logic

Basic rate limiting often starts with an IP address. That is an understandable first step, but it is not enough for account protection. Attackers rotate through proxy networks. Legitimate users may share a carrier or office IP. Some attacks are low and slow enough that no single IP looks exceptional.

For account journeys, rate limiting needs to be tied to the thing being protected.

Login attempts can be counted differently from password resets. Token refreshes can be counted differently from product searches. A failed authentication response can be treated differently from a normal read request. A route hit by a first-seen client can be treated differently from one used by a known browser session.

That is the point of API protection as an operating layer, not just an API inventory exercise. The route, schema, authentication state, bot signal, and rate key should be available to the same decision. Otherwise teams end up writing compensating rules in several systems and hoping the gaps line up.

The Edge Decision Needs Options

Not every suspicious request should be blocked. Some should be logged. Some should be rate limited. Some should be challenged. Some should be allowed because the business impact of a false positive is worse than the risk presented by that specific request.

Account protection is strongest when the action matches the journey.

A login request with weak risk signals might be allowed but watched. A password reset request with stronger signals might require step-up. A checkout attempt from a newly compromised session might be blocked or reviewed. A partner API key exceeding expected usage might be throttled without affecting normal customers.

Peakhour's position here is simple: API, bot, WAF, rate, and account controls work better when they share request evidence. That can run on Peakhour Edge, or it can sit beside the CDN and cloud edge already in place through bring your own edge. The important part is not the label on the component. It is whether the request path has enough context to make the right decision.

Account Protection Is a Journey Control

A useful account protection programme should be able to answer operational questions.

Which routes are involved in account takeover attempts?
Which sessions moved from suspicious login behaviour into account changes?
Which tokens or API keys are behaving outside their expected pattern?
Which controls created friction, and where?
Which blocked requests actually protected account, checkout, or recovery actions?

Those questions cannot be answered from a login form alone. They require API visibility, account-event context, rate data, bot signals, and reviewable evidence.

That is the thesis of this series: API protection and account protection are one request-path problem. The account is compromised through a sequence of requests. The defence needs to see that sequence early enough to act.

For teams already working on account takeover prevention, the next step is not simply adding another login prompt. It is connecting the account journey to the API routes that now carry it.

The Real Cost of Breached Credentials

2026-06-19T00:00:00+10:00

The cost of breached credentials is usually counted in the wrong place.

When an organisation suffers a data breach, the obvious costs are incident response, legal work, notification, customer support, remediation, and regulatory attention. Those costs matter. IBM's 2025 Cost of a Data Breach Report puts the global average breach cost at about USD 4.4 million. IBM's data breach explainer also says stolen or compromised credentials were one of the top five initial attack vectors in the 2025 report, accounting for 10% of breaches and taking up to 186 days to identify.

But that is only the first bill.

Once usernames and passwords leave the original system, they do not stay attached to the original incident. They are copied, sorted, bundled, tested, resold, and mixed with other personal data. Another company's breach becomes your login problem. A password reused somewhere else becomes your fraud queue, your support call, your chargeback, your locked account, your angry customer, and your next security review.

That is the real cost of breached credentials: not just the breach, but the long tail of account abuse that follows.

The Roundup: Breaches Are Feeding Account Abuse

The numbers are not subtle.

The Identity Theft Resource Center's 2025 Annual Data Breach Report tracked 3,322 data compromises in 2025, a record high and a 79% increase over five years. The same report found that 70% of breach notices did not include attack information, making it harder for consumers and downstream businesses to understand what risk they now carry.

The ITRC also introduced a category it calls Previously Compromised Data: old stolen data that is repackaged and recirculated. In the full report, the ITRC says there were four major PCD releases in 2025, including two incidents involving roughly 16 billion records with no known notices. Its warning is the important part: while this may not be "new" stolen data, aggregation makes it highly effective for credential stuffing and account takeover attacks.

That matches the operational pattern security teams see on login endpoints. OWASP describes credential stuffing as automated testing of stolen username and password pairs against login forms. The reason it works is boring and persistent: people reuse passwords. Attackers do not need to breach your site if a customer has already reused a working credential somewhere else.

For Australian organisations, the local signals are just as relevant. The OAIC received 532 Notifiable Data Breach notifications between January and June 2025, with malicious or criminal attacks remaining the largest source of notifications. ASD's Annual Cyber Threat Report 2024-25 notes that its credential exposure notification process proactively sent 9,587 credential exposure events to about 220 organisations between 19 November 2024 and 30 June 2025.

None of that means every fraud loss starts with a reused password. It does mean credential exposure is part of the operating environment. Attackers have supply, tooling, proxy infrastructure, and plenty of places to turn account access into money.

The FBI's 2025 IC3 report gives useful context for that monetisation path. Cyber-enabled fraud accounted for 452,868 complaints and USD 17.697 billion in reported losses. Those losses include many crime types, not just credential stuffing, but the transaction paths are familiar to anyone dealing with account abuse: wire and ACH transfers, cards, peer-to-peer transfers, prepaid and gift cards, and cryptocurrency.

Where the Cost Actually Lands

A breached credential is cheap for the attacker and expensive for everyone else.

The first cost is detection. A login using the right username and password does not automatically look malicious. If the attacker spreads attempts across residential proxy infrastructure, uses one attempt per account, or targets mobile API endpoints directly, simple IP-based rate limits may not see the pattern. Peakhour has written about this in The Australian epidemic of Account Takeover attacks and in Credential Stuffing Does Not Stop at the Login Form.

The second cost is fraud. Once a credential works, the attacker looks for value: stored cards, gift cards, loyalty points, refunds, store credit, subscription changes, delivery addresses, and saved payment flows. This is why account takeover is not just an authentication problem. The expensive moment may be checkout, not login.

The third cost is support. Customers do not usually know whether the original password leak happened somewhere else. They know their account was used, their card was charged, their loyalty balance disappeared, or their email address changed. The business still has to handle the support ticket, freeze the account, unwind the transaction, review the evidence, and explain what happened.

The fourth cost is trust. We have covered this before in The Cost of Credential Stuffing: the reputational damage is practical. Customers see refunds, account locks, suspicious messages, and public complaints. Even if the business was not the source of the original breach, it becomes the place where the harm is felt.

The fifth cost is friction. If the only response is to challenge everyone, the business pays through abandonment and customer frustration. If the response is too soft, the business pays through fraud. The work is to apply friction where the evidence justifies it.

You Do Not Need Surveillance to Secure Accounts

There is a bad version of account protection that tries to identify people everywhere they go. That is not necessary, and it is not the right model for this problem.

Credential abuse defence should be scoped to the account security decision in front of you. Is this login using a known exposed credential pair? Is the session coming from suspicious infrastructure? Is it a first-seen device for the account? Is it trying to change email, reset the password, add a payout method, redeem stored value, or check out with saved payment details? Did the same client pattern just test many accounts?

Those questions can be answered with security-specific signals, not advertising-style tracking. Hash the credential check. Treat fingerprints as evidence, not identity. Keep the evidence tied to the protected account and request path. Use network, device, route, behaviour, and credential-risk context to decide whether to allow, step up, throttle, block, or review. Do not build a cross-site identity graph when the job is to stop account abuse on your own service.

That distinction matters. Users should not have to trade privacy for basic account security. Businesses also do not need to choose between doing nothing and adding blanket friction. Contextual security is useful because it lets the response match the risk.

What Teams Should Measure

If breached credentials are a business cost, measure them like one.

Useful measures include:

How many login attempts match known breached credential pairs.
How many breached-credential attempts result in a successful login.
Which routes see the risk: login, password reset, email change, stored-card checkout, gift card redemption, account recovery, mobile API, partner API, or admin access.
How often high-risk sessions move from login into sensitive account actions.
Which signals appear together: breached credential, residential proxy, first-seen device, unusual geography, repeated failure, rapid checkout, or recovery-flow pressure.
How many support tickets, refunds, chargebacks, account locks, and fraud reviews are linked to account takeover.
How many controls create customer friction, and whether that friction is landing on risky sessions or ordinary customers.

This does not need to be perfect on day one. The important step is to stop treating credential stuffing as a vague security category and start treating it as an observable account-risk workflow.

The Control Pattern

The control pattern is layered.

Start with breached credential scanning so reused or exposed credentials are visible at login. Feed that signal into account takeover prevention rather than treating it as a standalone report. Add bot management and advanced rate limiting so automation and distributed testing are harder to run at scale. Use residential proxy detection as a risk signal, especially where attackers are trying to make automated traffic look like normal customer traffic.

Then carry the risk forward after login.

A low-risk page view and a saved-card checkout should not inherit the same level of trust just because the password worked. A session that begins with a breached credential match, comes through suspicious infrastructure, and immediately changes the email address or redeems stored value deserves a different response from a known customer browsing order history.

The response can be graduated:

Log low-risk activity for visibility.
Tighten rate limits on suspicious automation.
Require step-up verification before sensitive account changes.
Hold or review risky transactions.
Notify the customer when high-risk account changes are attempted.
Block sessions when the evidence is strong enough.

That is how breached credential data becomes useful. It is not a panic button. It is a signal that helps decide when trust should be earned again.

The Practical Takeaway

Breached credentials are not only a breach-response issue. They are an account protection issue, a fraud issue, a support issue, and a customer trust issue.

The original breach may have happened somewhere else. The cost can still land on your login form, your checkout, your API, and your support team.

The goal is not to make every login difficult. The goal is to make stolen credentials harder to turn into account control, money movement, stored-value abuse, or customer harm.

That starts by making credential risk visible, connecting it to session and route context, and applying proportionate controls where the cost would otherwise show up.

Credential Stuffing Does Not Stop at the Login Form

2026-06-19T00:00:00+10:00

Credential stuffing is usually described as a login problem. An attacker takes breached username and password pairs, tests them against a site, and tries to find accounts where people reused passwords.

That description is accurate, but incomplete. The login is only the first gate. The real damage often happens in the flows that follow a successful login: password reset, email change, saved cards, loyalty balances, gift cards, account recovery, address changes, and checkout.

If account protection only watches the login form, it can miss the part of the attack that matters most to the business.

A successful credential stuffing attempt does not always look dramatic. The attacker may have valid credentials. They may come through residential proxy infrastructure. They may spread attempts across many IP addresses. They may slow the attack down to stay below simple thresholds. If the site treats a valid username and password as the end of the risk decision, the attacker inherits whatever the account can do.

That is why account takeover prevention needs to cover account actions, not just authentication.

The Attack Continues After the Password Works

Once an attacker is inside an account, they usually want persistence, value, or both.

A password reset or password change can lock the real customer out. An email change can move alerts, receipts, and recovery messages away from the owner. A phone number change can weaken later verification. A new shipping address can redirect physical goods. Stored payment methods can turn account access into immediate fraud. Gift cards, store credits, loyalty points, and refunds can be easier to monetise than a card transaction.

Checkout is often where the compromise becomes visible, but the risk builds earlier. A login from unfamiliar infrastructure followed by a profile change, then a saved-card purchase, is different from a returning customer browsing previous orders. A dormant account that suddenly redeems gift cards, changes email, and ships to a new address deserves more scrutiny than an ordinary login.

These flows are also common in APIs. Mobile apps, single-page applications, partner integrations, and checkout backends expose account actions through endpoints that may not share the same controls as the web login page. Attackers do not care whether the valuable step is behind /login, /api/account/email, or /checkout/payment. They follow the path that works.

Breached Credentials Are a Risk Signal

Breached credential checks are useful because they add context before the account is fully trusted. If a credential pair is known to have appeared in a breach, the site can treat the session differently from the start.

That does not mean every breached credential attempt should be handled the same way. A user may be genuinely logging in with a reused password. An attacker may be testing a combo list. A customer may be returning after a long period away. The point is to make the risk visible and carry it through the session.

Peakhour has written before about managing breached credential usage. The practical lesson is that credential risk should feed the wider account protection decision. A breached credential signal should be considered alongside client evidence, network context, request rate, route sensitivity, behaviour, and the action being attempted.

A low-risk page view and a stored-card checkout should not inherit the same confidence just because both follow a successful login.

MFA Helps, But It Does Not Close Every Path

Multi-factor authentication remains useful. It can stop many direct account takeover attempts and raise the cost of abuse. But MFA is not a complete defence when attackers use social engineering, session theft, weak recovery flows, trusted devices, or post-login actions that do not require step-up verification.

The better pattern is adaptive control. Let the login succeed when the evidence is low risk. Step up when the action matters. Ask for stronger verification before changing the email address, adding a new payout method, redeeming a stored balance, or checking out with saved payment details from an unfamiliar context.

This is not about adding friction everywhere. It is about reserving friction for the points where compromise turns into loss.

What to Monitor After Login

The useful signals are operational and specific:

Credential risk at login, including known breached username and password pairs.
New client, browser, or network evidence on an existing account.
Password reset, password change, email change, and phone change attempts.
New shipping addresses, payment method changes, stored-card use, gift card redemption, and loyalty balance activity.
Sudden changes in behaviour, such as rapid checkout after login or repeated account recovery attempts.
API routes that perform sensitive account actions without the same scrutiny as browser flows.

The response should match the confidence and consequence. Some events only need logging. Some need tighter rate limits. Some need a browser challenge, MFA step-up, temporary hold, customer notification, or review.

Credential stuffing defence is not finished when a password works or fails. The more useful question is: what does this session try to do next, and does the evidence justify trusting it?

For account protection, that is the line that matters.

Fingerprints Are Evidence, Not Identity

2026-06-19T00:00:00+10:00

The word "fingerprint" can create the wrong expectation.

In security, a browser or network fingerprint is not the same as a human fingerprint. It does not prove who a person is. It does not remove uncertainty. It should not be treated as a permanent identity for a customer.

A fingerprint is evidence. Sometimes it is strong evidence. Sometimes it is weak, common, stale, or deliberately manipulated. Its value comes from how it is combined with route, behaviour, account state, network context, credential risk, and the action being requested.

That distinction is more than wording. It affects how security teams design controls, explain decisions, and avoid overblocking legitimate users.

What Network Fingerprints Can Tell You

Network fingerprinting compares connection and protocol evidence. TCP behaviour, TLS handshakes, JA3 or JA4-style representations, HTTP/2 settings, header shape, MTU, proxy indicators, ASN, and path characteristics can all help classify the client or infrastructure behind a request.

That can be useful during credential stuffing, scraping, scanning, API abuse, or Layer 7 attack pressure. Attackers may rotate IP addresses, but parts of the client stack or automation framework can remain consistent. Grouping requests by network evidence can make rate limiting, bot detection, and investigation more precise than IP-only rules.

But the fingerprint is still not identity.

Common browsers can share similar network shapes. Mobile networks and carrier-grade NAT can make unrelated users appear close together. VPNs and residential proxies can distort source context. Browser and library updates can change fingerprints overnight. Hashing can make signals portable while hiding useful detail. Attack tools can also try to imitate normal clients.

The right conclusion from a suspicious network fingerprint is not "we know who this is". It is "this request deserves a different level of confidence".

What Browser Fingerprints Can Add

Browser fingerprinting adds evidence from the application layer and, where appropriate, browser-side checks. Headers, client hints, JavaScript-visible properties, rendering behaviour, storage behaviour, timezone, language, permissions, and API availability can help decide whether a request looks like the browser it claims to be.

This matters because many attacks try to borrow the appearance of ordinary browser traffic. Automation frameworks, emulators, headless browsers, anti-detect browsers, and scripted API clients can all present a user-agent string that looks plausible. Browser evidence helps compare the claim with the rest of the request.

Again, the useful output is confidence, not identity. A browser fingerprint might support a challenge. It might support a lower rate limit. It might explain why a session changing an email address needs step-up verification. It might help bot management separate obvious automation from normal traffic.

It should not become a claim that one technical pattern equals one person.

The Comparison Matters

Peakhour's page on browser fingerprinting vs network fingerprinting makes the operational split clear. Network fingerprints usually come from passive connection and protocol evidence. Browser fingerprints often involve request and browser-side evidence. They answer related but different questions.

A strong decision often needs both.

A request claiming to be a normal browser should look broadly consistent across TLS, HTTP/2, headers, JavaScript-visible browser properties, proxy context, route behaviour, and account history. If the browser looks normal but the network path resembles a known automation cluster, that is useful. If the network path looks ordinary but the browser evidence is inconsistent or missing on a sensitive route, that is useful too.

The mismatch is the signal. The response still depends on consequence.

A suspicious request to a public asset route might only need logging. The same evidence on login, password reset, stored-card checkout, account email change, admin access, or an expensive API route may justify a challenge, tighter limit, temporary hold, or review.

How to Use Fingerprints Responsibly

Fingerprints work best when they are attached to an explainable decision. A security event should show the route, account or token context where relevant, source network evidence, browser evidence, policy action, response code, and review outcome. That gives operators a way to understand and correct decisions.

Peakhour's guide to network fingerprint signals and security decisions frames the choices properly: allow, log, challenge, rate limit, block, or review. A fingerprint should help choose among those actions. It should not replace judgement.

Responsible use also means accepting uncertainty. Fingerprints collide. They drift. They can be spoofed. Some privacy tools intentionally reduce or alter browser signals. Some legitimate users have unusual configurations. Some high-risk requests have only partial evidence.

That uncertainty does not make fingerprints useless. It means they should be one layer in a wider control set.

For account and API security, the practical question is not "can this fingerprint identify a person?" It is "does this evidence change the confidence we should place in this request?"

If the answer is yes, use it carefully. Increase scrutiny on sensitive actions. Reduce friction where evidence is clean. Preserve enough context for review. Avoid pretending that a technical fingerprint is a human identity.

That is the more accurate model, and it leads to better security decisions.

For a protocol-level example, see A network fingerprint is a cohort, not a client. It compares the information retained by JA3, JA4 and Cisco Mercury and explains why a matching TLS value can still cover many applications and users.

Account Security Without Tracking People

2026-06-19T00:00:00+10:00

Account security needs evidence. A login request is not just a username and password; it has a route, client context, browser behaviour, network path, timing, session history, credential risk, and follow-on actions. Without some of that context, defenders are left with blunt controls: block too much, challenge everyone, or trust too easily.

The privacy problem starts when security teams confuse evidence with identity.

A risk signal should help answer a narrow operational question: should this login, password reset, email change, API call, or checkout step be allowed, challenged, rate limited, blocked, logged, or reviewed? It should not become a general-purpose profile of a person.

That distinction matters. Good contextual security is not surveillance dressed up as account protection. It is purpose-bound telemetry used to make proportionate security decisions.

Minimise the Signal Set

Security teams should start with the action they are protecting.

A login attempt may need credential risk, source network context, browser consistency, known client status, failed-attempt history, and session age. A password reset may need different evidence. A checkout using stored payment details may need another set again. There is rarely a good reason to collect every possible signal for every route.

This is especially important with browser and device evidence. Browser fingerprinting can include headers, client hints, JavaScript-visible properties, rendering behaviour, storage behaviour, timezone, language, and other consistency checks. Those signals can be useful for detecting automation, anti-detect browsers, session abuse, and high-risk account changes. They can also be privacy-sensitive if collected broadly or retained without a clear purpose.

The practical standard should be simple: collect what is needed for the account defence decision, attach it to that decision, and avoid turning uniqueness into the goal.

Use Evidence Over Identity

A security system does not need to know who a person "really" is to make a better login decision. It often only needs to know whether the request looks consistent with the account, route, browser, network path, and recent behaviour.

That is where verified browser trust fits. The point is not to label a human being. The point is to decide whether a browser-like request has returned enough trustworthy evidence to proceed on a sensitive path. If the evidence is weak, the system can choose a proportionate response: log, challenge, rate limit, step up authentication, or send the event for review.

Network evidence should be handled the same way. Network fingerprint signals can help distinguish ordinary browser traffic from automation, proxy paths, unusual client stacks, or inconsistent request shapes. But a network signal is not a person. It is one piece of evidence attached to a request.

That framing reduces overreach. It also improves operations because decisions remain reviewable. If a customer is challenged, support and security teams should be able to see the route, risk signals, and policy reason without needing a vague black-box identity claim.

Be Careful With Behavioural Analytics

Behavioural analytics can help detect account compromise, especially when a session changes sharply from normal account usage. A customer who normally logs in from one region and browses slowly may deserve extra scrutiny if the same account suddenly logs in from unfamiliar infrastructure, changes email, redeems stored value, and checks out quickly.

But behavioural systems have limits.

Some users are sporadic. Some travel. Some use privacy tools. Some share devices. Some change browsers or phones. Some only visit when there is a problem. If there is not enough history, the system should admit that uncertainty rather than pretending the baseline is stronger than it is.

That is where adaptive security is useful. Low-confidence evidence does not always justify a hard block. It might justify logging, a lower rate limit, a step-up challenge on a sensitive action, or a temporary hold on a risky change.

The aim is not perfect recognition. It is better decision-making under uncertainty.

Make Retention and Purpose Part of the Design

Privacy-respecting account security is not only about which signals are collected. It is also about how long they are kept, where they are used, and who can inspect them.

Useful practices include:

Tie telemetry to account defence purposes such as login risk, bot detection, account recovery, checkout abuse, and API misuse.
Prefer route-specific evidence over broad user profiling.
Keep raw signals only where they are needed for detection, audit, or investigation.
Store decision evidence in a way operators can review.
Avoid using security telemetry for unrelated marketing or behavioural targeting.
Tune controls so low-risk users are not repeatedly challenged without cause.

Peakhour should not pretend that account security can happen with no fingerprints, no telemetry, and no judgement. Modern attacks abuse valid credentials, residential proxy paths, automation frameworks, API routes, and post-login workflows. Defenders need evidence.

The privacy-respecting position is narrower and stronger: collect the right evidence for the security decision, minimise it, keep it purpose-bound, and treat fingerprints as confidence signals rather than personal identity.

That is how account security can become safer without turning every login into tracking for its own sake.

How Residential Proxies Changed API and Account Abuse

2026-06-19T00:00:00+10:00

Residential proxies have changed the shape of API and account abuse. The old picture was easier to reason about: too many failed logins from one IP, a known hosting provider range, an obvious bot user agent, or a burst that crossed a threshold quickly enough to trip a rule.

That still happens, but it is not the harder problem.

The harder problem is the attempt that arrives through ordinary consumer networks, spreads itself across many addresses, and behaves just slowly enough to avoid looking like an incident. One login attempt here. A password reset probe there. A token refresh pattern that is unusual only when it is seen beside the route, the client, the ASN, the credential history, and the account event.

That is why residential proxy detection should be treated as part of the account and API decision path, not as a standalone allow/block list.

The Account Workflow Is Now a Distributed Target

Attackers do not need to break the whole application at once. They can work through the account surface in pieces:

Login attempts against known usernames.
Password reset initiation and verification.
New account registration.
Token issue and refresh routes.
Payment, address, profile, and email changes.
Loyalty, wallet, checkout, or stored-value workflows.
API calls that reveal whether an account or credential is valid.

Each route may look acceptable in isolation. The risk appears when the pattern is joined together.

A residential proxy network helps the attacker keep that pattern quiet. Requests rotate through many residential-looking exits. IP-based rate limits see different sources. A reputation feed may not have labelled a fresh or private proxy network yet. Geo checks can look plausible enough. The traffic does not necessarily arrive as a clean burst.

This is where static thinking breaks down. If the only question is "is this IP bad?", the answer will often arrive too late or be too blunt to use safely.

Fresh and Private Proxy Networks Create a Timing Problem

Many teams think about proxy detection as a database problem: look up the IP, see whether it is a proxy, then block it. That works for some traffic, especially known data centre proxies and commodity infrastructure.

Residential proxy abuse is less tidy. Fresh networks can appear before public datasets have a confident label. Private networks may not show up in broad feeds at all. Some exit points are shared with legitimate users. Some sit behind carrier-grade NAT or normal household connections. Blocking the address outright can create customer pain, while allowing it without context leaves the account flow exposed.

This is the practical reason Peakhour talks about residential proxy use as a signal. The signal matters, but it has to sit beside IP intelligence, connection characteristics, client history, request behaviour, account state, and route sensitivity.

A residential proxy on a marketing page may only need logging. The same proxy signal on a login route with recent failures may justify a challenge. On a password reset or high-value account change, it may justify step-up authentication, throttling, or blocking depending on the rest of the evidence.

The control should match the risk of the action.

Low-and-Slow Behaviour Is Still Automation

Low-and-slow abuse is uncomfortable because it avoids the easy operational story. There is no dramatic spike. There may be no single IP worth banning. The application may not be overloaded. Support may only see a few confused users, a few locked accounts, or a gradual rise in reset attempts.

For API and account workflows, this is still automation. It just looks less like a flood and more like a background process.

Useful signals include:

Repeated failed authentication across a shared fingerprint or client pattern.
Many accounts touched by similar request timing.
Token or reset routes used out of sequence.
Browser characteristics that do not match the claimed client.
Residential proxy use on sensitive account routes.
Fresh IP or ASN patterns appearing around account events.
Similar request shapes distributed across unrelated accounts.

None of these signals has to prove abuse by itself. The point is to combine them early enough that the application does not have to make the decision alone.

Peakhour's view is that proxy detection belongs in the same operating model as bot management, rate limiting, account risk scoring, and event evidence. The useful question is not "can we block every residential proxy?" It is "what should this route do when proxy use appears with this account, this client, this credential pattern, and this recent behaviour?"

API Routes Need the Same Treatment as Browser Flows

A common gap is protecting the visible login page while leaving API routes with weaker controls. Browser-side checks can help on web flows, but many account actions now happen through mobile apps, single-page applications, partner integrations, and backend APIs.

Those routes still need context. They need request-level validation, route-aware thresholds, proxy and IP signals, token checks, and evidence that can be reviewed later. A login API, a reset API, and a profile-change API should not all receive the same action just because the source address has the same reputation.

This is also why rate limiting has to move beyond source IP. A rule can key on a token, header, fingerprint, account identifier, route, response code, or a combination of signals. That makes it possible to slow failed login behaviour without punishing every legitimate user behind the same network.

The background reading on proxy detection challenges and quantifying residential proxy risk covers the broader detection problem. For API and account teams, the immediate step is more operational: find the routes where a residential proxy signal should change the action.

The Right Outcome Is Controlled Friction

Residential proxy detection is not a magic verdict. It is a way to make the account decision more honest.

Some traffic should pass. Some should be logged. Some should be rate limited. Some should be challenged. Some should be blocked. The difference should come from route sensitivity, request context, and observed behaviour, not from a single IP label.

A practical policy might look like this:

Monitor proxy use across all account and API routes.
Apply tighter thresholds on login, reset, token, and account-change routes.
Combine proxy use with credential, client, rate, and behaviour signals.
Preserve decision records so security and support can explain what happened.
Move from monitor to enforce only after reviewing false positives and customer impact.

That model gives teams a way to respond to residential proxy abuse without turning every shared residential network into a casualty.

For a grounding definition, see What is Residential Proxy Detection?. For the product control, see Residential Proxy Detection.

The important shift is simple: residential proxies are not just a network category. In account and API protection, they are context for deciding how much trust a request deserves.

Shadow APIs Are Account-Abuse Paths

2026-06-19T00:00:00+10:00

A shadow API is not dangerous because it has a mysterious name. It is dangerous because it still accepts requests.

If an endpoint can reset a password, refresh a token, check an account, change a delivery address, apply a discount, validate a stored payment method, or expose customer data, it is part of the account-abuse surface. Whether it appears in the current OpenAPI file is secondary.

Attackers do not need your API catalogue to be tidy. They need one working route that your normal controls do not understand.

The Forgotten Paths Are Often Real Paths

Most organisations have more API surface than they think.

Mobile apps leave behind old versions. Partner integrations get built for a campaign and then stay online. Browser-backed APIs are treated as internal because they are called by the front end, even though anyone can inspect and replay the requests. Legacy account endpoints remain active because turning them off might break an unknown client.

None of this is unusual. It is how real systems evolve.

The risk appears when those routes keep accepting production traffic without the same security treatment as the visible application. A current login page may have bot detection, adaptive prompts, and tuned rate limits. An older mobile endpoint may only check whether the credentials are valid. A partner route may trust an API key that has not been rotated. A browser API may return more account state than the front end displays.

That gap is where account abuse gets practical.

Unknown Does Not Mean Unused

Security teams sometimes talk about discovery as if the main outcome is a cleaner inventory. Inventory matters, but the more useful question is: what can this route do?

A shadow API that serves public catalogue data has one risk profile. A shadow API that changes account details has another. A forgotten token endpoint is different again. A mobile route that accepts username and password combinations is a credential stuffing target, even if the public login page has already been hardened.

This is why API security has to stay connected to account context. Route discovery is only the start. The protection model needs to know method, schema, authentication state, response pattern, user journey, and business sensitivity.

A POST request to an account recovery endpoint deserves different treatment from a GET request to a static content API. A password reset route used by a first-seen client through rotating proxy infrastructure is not the same as the same route used by a known customer session.

The route matters because the account outcome matters.

Browser-Backed APIs Are Still APIs

A common blind spot is the API behind the web application.

The front end might make a neat request to /api/account/profile, /api/cart/apply-coupon, or /api/session/refresh. Because the route was designed for the browser, teams may assume the browser is the control. It is not.

Requests can be replayed outside the page. Headers can be copied. Tokens can be stolen. User agents can be faked. Automation can follow the same sequence as the application, only faster and at scale.

The right response is not to treat every browser-backed API as hostile. The right response is to attach evidence. Is this a known browser session? Is the TLS and HTTP behaviour consistent? Is the request sequence normal for the journey? Is the session suddenly moving from login to sensitive account changes? Does the schema match what the route expects?

Those questions sit between basic definitions of what API security is and the operational work of stopping abuse.

Mobile and Partner APIs Need Ownership

Mobile and partner APIs create a slightly different problem. They often have legitimate non-browser clients, so crude controls can break real use.

A mobile app may have older versions in the field. A partner may send traffic from fixed infrastructure, or from changing cloud infrastructure. A service client may authenticate with an API key rather than an interactive user session. Some requests will look less browser-like because they are not meant to be browsers.

That makes ownership important.

Each route should have an owner, expected clients, authentication model, rate expectation, schema expectation, and deprecation plan. API keys should be treated as credentials, not configuration strings. OAuth and JWT use should include short-lived access, appropriate scopes, and validation at the endpoint. Legacy flows should not survive indefinitely just because nobody is sure what they support.

For REST services, that discipline includes the basics covered in REST API security: method control, status-code handling, input validation, token handling, rate limiting, and useful logging. The account-abuse angle is narrower and more operational: which of these controls tells us whether this request can harm a customer account?

Discovery Has to Feed Enforcement

A report listing unknown endpoints is useful for a week. A discovery process that feeds policy is useful every day.

When a new route appears, the security question should be concrete:

Who owns it?
Is it authenticated?
Does it match a known schema?
Does it touch account state?
Can it reset trust, change value, or expose customer data?
What rate and behaviour patterns are normal?
Which action should apply when it is abused?

That is where API protection use cases become more than documentation. The goal is not to produce a perfect catalogue for its own sake. The goal is to reduce the number of unknown request paths that can be used for account abuse.

Shadow APIs are not a separate class of attack. They are normal APIs without enough operational visibility.

And when they sit on account journeys, they become a direct path from unknown surface to customer harm.

Price Transparency Is Now a Data Access Problem

2026-05-18T00:00:00+10:00

Australia's supermarket pricing debate can look like a consumer pricing story.

For digital teams, it is also a bot and API protection story.

The ACCC's final supermarket inquiry recommended that ALDI, Coles, and Woolworths publish prices on their websites. It also recommended that Coles and Woolworths make dynamic price APIs available for third-party comparison tools.

Then, on 18 May 2026, Guardian Australia reported on CW Scanner data about Coles and Woolworths promotion patterns. For digital teams, the operational detail is this: the report said CW Scanner's operator stated the service was not scraping, and instead used the supermarkets' website application programming interfaces.

That does not settle questions about permission, terms of use, supermarket approval, or the status of any specific API. It does make the practical problem sharper.

Price transparency increasingly depends on automated access to current data.

Every automated request still needs a decision.

APIs do not remove the bot problem

It is tempting to treat an API as the clean alternative to scraping. Sometimes it is cleaner. A documented API can make access more predictable, auditable, and easier to govern than repeated extraction from product pages.

But an API is still an automation surface.

The same retailer or marketplace may need to support:

public product pages;
price, promotion, search, listing, catalogue, and inventory routes;
browser-backed application calls;
documented APIs and partner feeds;
comparison tools and public-interest services;
search engines, monitoring systems, and accessibility tooling;
unknown collectors rebuilding price, inventory, availability, or ticketing datasets outside the intended access model.

Some of that traffic is useful. Some is commercially necessary. Some is abusive. Much of it will not identify itself honestly.

So the question is not "should bots be blocked?"

The question is: can you tell intended automated access from uncontrolled extraction?

The decision needs evidence

A blanket "block all automation" position can break comparison services, partner integrations, search visibility, monitoring, accessibility tooling, and APIs that were built to be automated.

A blanket "allow everything" position can expose pricing, product, inventory, account, checkout, ticketing, and API paths to extraction and abuse.

The practical middle ground is governed automation:

publish the access you want to support;
recognise the clients and behaviours you expect;
validate API route, schema, method, authentication, and client context;
detect traffic that has drifted from the intended use;
keep decision logs so security, legal, product, and commercial teams can review what happened;
respond proportionately with allow, log, rate-limit, challenge, block, or review decisions.

That is where bot protection becomes more than a yes-or-no control.

It supplies the evidence behind each access decision.

Where Peakhour fits

Scraping protection should identify repeated extraction across product, price, search, listing, catalogue, article, inventory, and availability routes. The goal is not to stop every non-human request. It is to separate expected access from collectors rebuilding data outside the site's control.

API bot protection applies the same discipline to automated API clients. APIs exist to be automated. The risk comes from unknown clients, unexpected route combinations, credential abuse, endpoint enumeration, excessive request volume, and business-logic abuse that generic perimeter controls cannot explain.

Bot management turns request evidence into a decision: allow trusted traffic, log expected automated access, rate-limit noisy collectors, challenge uncertain sessions, block confirmed abuse, or send edge cases to review.

Verified browser trust adds a useful signal when browser-backed journeys are being automated or replayed. Headers and cookies can be copied, proxy networks can rotate, and automation can mimic ordinary navigation. Peakhour can challenge the browser path, verify that the expected evidence came back, and attach that witness to the wider decision record.

That browser signal does not, by itself, prove the user, device, or account is trustworthy. It helps the risk engine decide what to do alongside route, proxy, device, behaviour, credential, and API context.

Why this matters beyond supermarkets

The ACCC's 2024 proceedings against Coles and Woolworths were about alleged false or misleading price statements, not supermarket price regulation, collusion, or anti-competitive conduct. The ACCC announced on 14 May 2026 that the Federal Court found Coles made false or misleading representations in 13 of 14 agreed sample "Down Down" tickets, with penalties and other orders still to be determined. For Woolworths, the separate "Prices Dropped" proceeding was awaiting judgment at publication.

Those legal details matter, but they are not the Peakhour point.

The Peakhour point is operational: when transparency, comparison, availability, or fairness depends on current digital data, organisations need a control plane that can support the access they intend and limit the extraction they do not.

That pattern shows up in retail, marketplaces, ticketing, travel, financial services, media, and any platform where public pages, browser-backed calls, and APIs expose commercially valuable data. It also shows up in adjacent problems like account abuse, checkout abuse, ticket scalping, product scraping, distorted analytics, and inventory harvesting.

The organisations that handle this well will not treat every automated request as the same.

They will be the ones that know what access they intend to allow, what behaviour they intend to stop, and why.

Cloudflare outage proves Plan B depends on controlling DNS

2025-11-18T21:00:00+11:00

On Tuesday, 18 November 2025, Cloudflare’s own status page marked every major service—CDN, Firewall, WARP, Workers, and the dashboard—as degraded for most of the day while engineers worked through an internal control-plane failure. The timeline moved from “Investigating” at 11:48 UTC to “Monitoring” after 14:42 UTC, and the incident wasn’t officially resolved until 19:28 UTC. During the worst of it, Cloudflare disabled WARP in London, bot scores seesawed, and customers were told to wait while remediation continued.

Waiting was the only option for many teams because their Plan B lived behind the same dashboard that was timing out. The top comment on the Hacker News thread was a set of curl commands for moving domains off Cloudflare’s proxy edge. Admins were stuck in 2FA flows trying to fetch an API token, or searching for Terraform credentials so they could toggle a proxied flag. That is not a resilience strategy.

We learned this lesson the hard way—and wrote about it after the 2021 Fastly outage in How to have a Plan B. The rule still stands: the platform you are trying to leave cannot be the only place that can change where your DNS points.

Detect: understand what’s actually broken

Incidents like Tuesday’s change shape quickly. Cloudflare’s own feed showed different failure domains every 30 minutes: bot management, dashboard auth, Access, WARP. The first mile is impartial telemetry that tells you what your users feel, not what the provider thinks. At Peakhour we stream real user monitoring, synthetic checks, and control-plane health from multiple CDNs and DNS partners. That lets us distinguish “cache errors in Hong Kong” from “global auth outage” and choose the right lever.

Decide: keep DNS authority in neutral territory

When your domain delegation lives with agnostic providers—Route 53, NS1, Azure DNS, or the enterprise registrar your legal team already approved—you can make failover decisions without pleading with a failing control plane. Peakhour doesn’t replace those vendors; we orchestrate them. We set short-but-safe TTLs, keep secondary answers staged, and continuously audit API access so we can flip traffic with one signed request. The minute you outsource DNS authority to a proxy CDN, you have given up the control that makes Plan B possible.

Divert: run the playbook in minutes, not hours

A workable Plan B has three moves:

Pre-stage alternate edges. Your secondary CDN, origin, or transit provider must be in sync with the active one—certificates, cache rules, WAF policies, everything. We keep them hot by replaying production configs across vendors.
Wire DNS automation. We integrate with multiple third-party DNS APIs at once so we can update apex A/AAAA, flattened CNAMEs, and geo/latency rules in a single workflow. Because the automation lives off the impacted platform, we can execute even while Cloudflare’s dashboard is returning 500s.
Drill humans on the handoff. Our SOC sits in Sydney and Melbourne, but we cover global hours. During an incident we line up Slack/Teams bridges with your SREs, confirm business impact, and keep execs in the loop while traffic drains to the healthy provider.

With that in place we routinely hit sub-five-minute diversion times, including DNS propagation, because the decision, the tooling, and the people are ready before the outage hits.

What Peakhour brings to your Plan B

Independent authority, familiar vendors. We leverage multiple established DNS providers instead of locking you into ours. You keep your contracts; we bring the automation and guardrails.
Unified multi-CDN config. Cache rules, image optimisation, WAF, and routing policies stay aligned across providers so you don’t lose capabilities when you switch.
Real drills, not just runbooks. Quarterly failover exercises prove that certificates, APIs, and humans are ready. We share the post-mortems so your execs see clear RTO/RPO numbers.
People you can phone. 24×7 Australian-based engineers who know your stack and can execute the play while your own team communicates with customers.

Book a resilience review

If Tuesday exposed that your failover path still depends on your primary provider’s dashboard, book a 30-minute Resilience Review with Peakhour and we’ll:

Map who really controls your DNS today.
Identify the gaps between your primary and standby CDNs.
Outline the automations we can layer on top of your existing DNS and hosting vendors.

The output is a concrete Plan B, a drill schedule, and a team that can execute it the next time a global provider blinks.

The BOTS Act and the War on Ticket Scalping

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

For popular concerts and events, tickets can disappear in seconds. Often the competition is not just other fans, but ticket scalping bots built to buy faster than a human can, then push those tickets into secondary markets at heavily inflated prices. The United States introduced the Better Online Ticket Sales (BOTS) Act to address that conduct. Whether it is working is less clear. Recent investigations into Ticketmaster suggest enforcement is still catching up.

Understanding the BOTS Act

Enacted in 2016, the Better Online Ticket Sales (BOTS) Act is a U.S. federal law aimed at giving consumers a fairer chance when buying tickets online. The law makes it illegal to use software, or "bots," to bypass security measures on ticket-selling websites.

Specifically, the BOTS Act prohibits:

Circumventing a security measure, access control system, or other technological control used by a ticket issuer to enforce purchasing limits.
Using a bot to purchase tickets in excess of posted limits.
Selling tickets that were acquired in violation of these rules, if the seller knew or should have known they were obtained illegally.

The aim was to stop scalpers using automated tools to buy tickets in bulk, so fans had a fairer chance of purchasing tickets at face value.

Australia's Approach

Ticket scalping bots are not only a U.S. problem. Other countries have also used legislation to protect consumers. In Australia, the state of New South Wales (NSW) became the first to outlaw ticket bots in 2017.

The legislation introduced heavy penalties, with fines up to $110,000 for corporations using bots to snap up tickets. The law also went further than the US BOTS Act by capping ticket resale prices at no more than 10% above the original price. At the time, a representative from TEG, the owner of Australia's largest ticket seller Ticketek, stated that bots accounted for up to 70% of activity on their website, showing how widespread the problem had become.

Ticketmaster Under the Microscope

Despite the BOTS Act being in place for years, ticket scalping persists. U.S. regulators have now turned their attention to the platforms themselves. In September 2025, reports emerged that the U.S. Federal Trade Commission (FTC) was investigating whether Ticketmaster, a subsidiary of Live Nation, was doing enough to comply with the BOTS Act.

The probe is reportedly examining whether the ticket seller has a financial incentive to allow resellers to circumvent its own rules. Ticketmaster denies wrongdoing and claims to block hundreds of millions of bots daily, but the investigation raises a direct question: are ticket platforms motivated to eliminate a secondary market from which they can also profit?

If the FTC pursues a case and finds Ticketmaster in violation, the penalties could be substantial. The law allows for fines of up to $53,000 per violation, which could translate to billions of dollars in penalties and put the rest of the industry on notice.

Renewed Political Pressure

Ticket scalping has also drawn direct political attention. In March 2025, President Donald Trump signed an executive order aimed at cracking down on ticket scalpers and price-gouging practices. The order specifically calls on the FTC to increase its enforcement of the BOTS Act, a piece of legislation that, despite being law since 2016, has been used to prosecute offenders only once.

The executive order also pushes for greater price transparency throughout the ticket-buying process and calls for investigations into unfair and anti-competitive practices in the secondary market. This follows similar efforts from the Biden administration, which had focused on eliminating "junk fees" and promoting all-in pricing. The bipartisan pressure points to a growing consensus that the current state of the ticketing industry is failing consumers.

The order received broad support from across the industry, with Live Nation, StubHub, and the National Independent Venue Association (NIVA) all voicing their approval. That support reflects a clear industry position: stronger enforcement of existing laws like the BOTS Act is a necessary step in protecting fans from scalpers.

Fighting on Two Fronts

While regulators are questioning Ticketmaster's efforts, the company has also used legal channels to fight bot operators. A notable case involved Prestige Entertainment, a ticket broker that Ticketmaster accused of using sophisticated bots to buy large quantities of tickets for resale.

In that lawsuit, Ticketmaster alleged that Prestige used bots and dummy accounts to bypass security measures like CAPTCHAs and purchase limits. The case produced some interesting legal arguments, including a novel copyright claim. Ticketmaster argued that in order to develop the bots, the software creators must have illegally copied code from Ticketmaster's website and app.

The legal battle ended in a settlement in 2019, with Prestige Entertainment permanently banned from using bots on Ticketmaster's platforms. The case shows that while Ticketmaster is under scrutiny itself, it has also pursued those who exploit its system. That leaves Ticketmaster fighting on two fronts: against bot operators, and now against regulators questioning whether its own enforcement is strong enough.

An Endless Cat and Mouse Game

The ticketing industry is locked in a constant technical arms race. As platforms like Ticketmaster develop more sophisticated security measures, bot creators find new ways to circumvent them. They use tools like residential proxies to mimic human users and distribute their attacks across thousands of IP addresses, making them difficult to detect.

Ticketmaster states it blocks 200 million bots a day, a fivefold increase from 2019. That figure shows the scale of the problem. The financial incentive for scalpers is large, and they are willing to invest heavily in technology to stay ahead.

For consumers, this means sold-out events and high resale prices are likely to continue. The BOTS Act provides a legal framework to punish offenders, but its effectiveness depends on enforcement and cooperation from major players like Ticketmaster. The current FTC investigation may show how much practical force the law has.

Agentic AI vs. Your API

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

For years, "bots" mostly meant simple, scripted programs. They followed rigid, predefined rules: if you see X, do Y. They were predictable. They could still do damage in attacks like credential stuffing, but their lack of intelligence made them relatively easy to detect. Their patterns were repetitive and clearly different from the complex, often messy, behaviour of human users.

That model is no longer reliable. The emergence of open and powerful reasoning models like DeepSeek has given rise to a new class of automation: agentic AI. These are not just scripts. They are autonomous agents that can reason, plan, and adapt their behaviour in real time. They don't need a human to write a script for every possibility. Give them a goal and they can work out the steps themselves. That changes the nature of automated threats, and security controls need to change with it.

The New API Consumer

Historically, APIs were consumed by two main groups: human users via a front-end application, and scripted bots following predictable patterns. Agentic AI introduces a third consumer, and one likely to become dominant. These AI agents are becoming primary users of web APIs, and they interact with them in materially different ways.

An AI agent can analyse an entire API surface in seconds, understand the relationships between different endpoints, and generate complex interaction patterns that a human developer would rarely attempt. They don't just follow a linear path; they can explore, learn, and optimise their interactions to achieve their goals, whether that's finding the best price on a product, gathering data, or probing for security weaknesses.

New Security Challenges: The Self-Hacking AI

The reasoning capabilities of these agents introduce security challenges that static, rule-based systems are poorly equipped to handle. An agentic AI doesn't just throw known exploits at a system; it can probe its defences and invent new attacks as it goes.

Consider a traditional Web Application Firewall (WAF) that relies on pattern-matching rules to block threats like SQL injection. An AI agent can send a series of carefully crafted requests, observe the WAF's responses, and systematically learn the structure of its rules. Once it understands the patterns the WAF is looking for, it can generate a custom exploit designed to bypass those rules while still achieving its malicious objective.

This isn't theoretical. Security teams are already reporting sophisticated attacks that adapt in real time, adjusting their tactics based on the system's defensive responses. These aren't simply pre-programmed behaviours; they are reasoning models at work.

A New Security Paradigm: From "Block Bots" to "Manage Agents"

The rise of agentic AI changes the security question. The old goal of "blocking all bots" is no longer viable or even desirable. AI agents will be used for both benign and malicious purposes. A customer's personal AI assistant booking a flight is useful automation; an attacker's AI agent trying to find vulnerabilities is not.

Bot management cannot stop at trying to keep automation out. It needs the intelligence to safely identify and manage AI agents. This requires moving away from static, signature-based detection and toward a more contextual, behavioural approach.

The key questions will no longer be "Is this a human or a bot?" but rather:

"What is the intent of this automated agent?"
"Is its behaviour consistent with a legitimate use case?"
"Can we trust this agent?"

This requires a new generation of security tools that can understand and adapt to agent behaviour, distinguishing between the legitimate AI assistants that will soon be a core part of our digital lives and the malicious ones that seek to exploit our systems. Organisations that fail to prepare for this shift risk having their defences systematically tested, mapped, and bypassed by the next wave of intelligent, automated threats.

Anatomy of a Credential Stuffing Attack

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

In early 2024, major Australian retailer The Iconic was hit by a widespread account takeover attack. Fraudsters used stolen credentials to log into customer accounts, place orders with stored credit cards, and ship goods to different locations. The incident caused significant reputational damage and financial loss, forcing the company to issue refunds and publicly address the security breach.

This attack wasn't the result of a direct hack on The Iconic's systems. It was a classic case of credential stuffing: an automated attack that works because people reuse passwords across services. This article breaks down how credential stuffing works, the attacker's toolkit, the business impact, and the controls that make it harder to run at scale.

What is Credential Stuffing?

Credential stuffing is an automated attack where malicious actors use lists of stolen usernames and passwords—often obtained from third-party data breaches—to gain unauthorised access to user accounts on other websites. The attack works because many users recycle the same password across multiple online services. If a password for a user's social media account is leaked, attackers will "stuff" that same email and password combination into the login forms of e-commerce sites, banking portals, and other high-value targets.

Because attackers submit valid credentials, even though they are stolen, these login attempts can be difficult to distinguish from genuine user activity. That makes credential stuffing harder for traditional security controls to spot.

The Attacker's Toolkit

Modern credential stuffing is not a manual process. Attackers use a mature set of tools and resources to automate and scale their campaigns:

Automation Software: Tools like OpenBullet are central to these attacks. OpenBullet is a powerful, open-source web testing suite that allows even non-programmers to create complex attack scripts. Attackers can find or create "configs" that tell the software exactly how to interact with a target website's login form.
Breached Credential Lists: Dark web markets carry massive databases of usernames and passwords harvested from data breaches. These "combo lists" are the raw material for credential stuffing attacks and can be purchased for very little cost.
Proxy Networks: To avoid being blocked, attackers distribute their login attempts across thousands or even millions of IP addresses. They often use residential proxy networks, which route traffic through the internet connections of real home users. This can make malicious traffic appear to come from legitimate customers, weakening IP-based blocking and rate limiting.

The Business Impact

The consequences of a successful credential stuffing attack extend beyond the login event:

Direct Financial Loss: As seen with The Iconic, attackers can make fraudulent purchases, drain loyalty points, or transfer funds, leading to direct financial losses and the cost of refunding customers.
Damage to Brand Reputation: Publicly reported breaches erode customer trust. Users who have been defrauded may share their negative experiences on social media, leading to lasting reputational harm.
Loss of Customer Trust: When customers believe their accounts are not secure, they may abandon the platform altogether, leading to customer churn and a decline in lifetime value.
Operational Costs: Responding to an attack involves significant operational overhead, including customer support time, fraud investigation, and new security measures.

Building a Multi-Layered Defense

Stopping automated attacks requires a defence strategy that goes beyond simple password policies. A modern, multi-layered approach should include:

Advanced Bot Protection: The first step is to distinguish bots from humans. Modern bot management uses techniques like network and browser fingerprinting, proxy context, route behaviour, and behavioural analysis to detect automated login attempts, even when they mimic human behaviour.
Check Credentials Against Breach Databases: Proactively check usernames and passwords used in login attempts against comprehensive databases of known breached credentials. If a credential pair is known to be compromised, you can flag the login for additional verification or alert the user to change their password.
Advanced Rate Limiting: Traditional IP-based rate limiting struggles against distributed attacks. Advanced rate limiting groups requests by more stable identifiers, such as a TLS fingerprint, which can remain consistent even as an attacker rotates through thousands of IP addresses. This helps track and block a single malicious actor launching a distributed attack.
Enforce Multi-Factor Authentication (MFA): MFA is not a silver bullet, but it provides a critical layer of security by requiring a second form of verification. Websites should strongly encourage or enforce MFA, especially for sensitive actions like changing account details or making purchases.

For production teams, the useful bot-management view ties those controls together on the login path. Credential exposure, residential proxy evidence, fingerprints, request rate, response codes, and session changes should feed one decision about whether to allow, challenge, rate limit, block, or review the attempt.

By combining these controls, organisations can make credential stuffing harder to scale, protect user accounts, and reduce the business risk when attackers test stolen credentials.

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.

The Invisibility Cloak

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

A bot can change its IP address without changing the browser behind the request. It can also change its reported browser profile while continuing the same account attack.

Residential proxies and anti-detect browsers cover those two surfaces. The proxy moves traffic through consumer connectivity. The anti-detect browser manages the client properties exposed to the website. Used together, they make simple IP and browser rules less reliable.

They do not make the operator invisible.

The Proxy Changes the Network Path

A residential proxy sends a third party's traffic through a consumer or ISP connection. The destination sees the exit address rather than the operator's original network.

That supply may come from an informed participant, an embedded monetisation SDK or a compromised device. The destination usually cannot see that enrolment history. It sees a request from an address that may also carry legitimate household traffic.

This is why a clean IP reputation result is not enough to establish trust. A fresh exit may not yet appear in a database, while a stale label can remain after the address has returned to ordinary use.

The Browser Changes the Client Presentation

An anti-detect browser lets an operator manage browser profiles at scale. Profiles can vary user agent, operating system claims, screen properties, language, time zone, storage and rendering inputs. The aim is to make separate sessions look plausible and prevent a site grouping them as one client.

That control is not absolute. Some properties can be spoofed cleanly. Others interact with the network stack, rendering environment, request sequence and account history. A profile can look plausible in isolation while disagreeing with evidence elsewhere in the session.

The stable explainer is Residential Proxies and Anti-Detect Browsers. This article focuses on what their combination changes for a live application.

Look for Agreement, Not a Magic Fingerprint

No fingerprint proves that two requests came from one person or one machine. Common browsers create large cohorts, privacy controls remove information, and legitimate devices change across software updates and networks.

The useful question is whether independent observations agree:

Does the TLS and HTTP behaviour fit the claimed browser family?
Does the browser profile remain internally consistent across the journey?
Does the same request sequence continue as the IP rotates?
Are credentials, accounts, carts or API objects reused across supposedly unrelated clients?
Do timing, retries and outcomes match normal use of the protected route?

Each observation has legitimate explanations. Agreement across several layers raises confidence without pretending a fingerprint is identity.

Protect the Work Being Attempted

Credential stuffing, fake registration, scraping and inventory abuse have different failure modes. Their controls should differ too.

On login, correlate failures across account, credential and client cohorts instead of resetting history with every IP change. On signup, measure creation velocity and the quality of later activity. On checkout, carry session risk into promotion, payment and inventory decisions. On APIs, use credentials, operations, protocol evidence and cost; JavaScript is not required.

Residential proxy detection contributes current network evidence. Browser and network fingerprinting contribute cohort and consistency evidence. Behaviour and route context decide whether the application should allow, log, challenge, rate limit, step up or block.

That is the important limitation of the “invisibility cloak” metaphor. These tools can hide one surface at a time. They still have to complete work against an application that can observe the whole request sequence.

Continue with Proxy Signals and Security Decisions or the route-specific guide Five Routes, Five Residential Proxy Decisions.

The CAPTCHA Conundrum

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

Remember the distorted, wavy letters you had to decipher to prove you were not a robot? That was CAPTCHA, which stands for "Completely Automated Public Turing test to tell Computers and Humans Apart." First developed in the early 2000s, its purpose was simple: create a challenge that humans could solve, but automated scripts, or bots, would struggle with.

For years, CAPTCHA was used across common web actions, from creating an account to posting a comment. But bots have improved faster than the test, while users have become less tolerant of friction. CAPTCHA now often fails in both directions: it interrupts legitimate users and can still be solved by automated campaigns.

The User Experience Problem: Killing Conversions

The biggest issue with visible CAPTCHAs is the friction they add to the user journey. Customers expect checkout, login, and form flows to be quick. Asking them to stop and solve a puzzle creates a clear point for abandonment.

The data is hard to ignore:

A landmark Stanford University study found that adding a CAPTCHA can reduce form conversions by up to 40%.
Research from bot management firm HUMAN Security revealed that 40% of real shoppers have abandoned a purchase because of CAPTCHA frustration.
Other analyses have shown that simply adding a CAPTCHA can lead to a 3.2% higher bounce rate and an overall 3-5% drop in conversions.

For an e-commerce business, losing up to 40% of potential sales at the final checkout step is not a marginal UX issue. These numbers map directly to revenue from legitimate customers who were annoyed, delayed, or unable to solve the puzzle. The impact is even worse for users with disabilities, for whom many visual CAPTCHAs are nearly impossible to complete.

The Security Problem: A Speed Bump for Bots

While CAPTCHAs frustrate legitimate users, they are often only a small obstacle for modern bots. A market exists for bypassing them at scale.

Attackers now use automated CAPTCHA-solving services, often called "CAPTCHA farms." These services use a combination of machine learning algorithms and low-wage human workers to solve CAPTCHAs in real time for a fraction of a cent per puzzle.

An attacker using an automation tool like OpenBullet can integrate with these services via a simple API call. When the bot encounters a CAPTCHA, it sends the puzzle to the solving service and receives the solution seconds later. In many cases, these services have a higher success rate at solving CAPTCHAs than actual humans.

That breaks the original CAPTCHA model. The test designed to block bots can now create a false sense of security while actively harming the experience for real users.

The Modern Alternative: Invisible Challenges

If visible CAPTCHAs are broken, what's the alternative? Modern bot management uses invisible challenges to verify users without causing friction. Instead of actively testing the user, these systems analyse background data to distinguish humans from bots.

This is achieved through a multi-layered approach:

Behavioural Analysis: These systems track subtle indicators of human behaviour, like mouse movements, typing cadence, and touchscreen interactions. Bots, even sophisticated ones, struggle to mimic these patterns consistently.
Network and Browser Fingerprinting: By analysing hundreds of data points from the browser and network connection, these systems can identify the tell-tale signs of automation, such as the use of data centre IPs, proxy networks, or inconsistencies in the browser fingerprint.
Machine Learning: Machine learning models are trained on vast datasets of human and bot traffic. They can identify complex patterns and adapt in real time to new and evolving bot techniques.

With this approach, most legitimate users never see a challenge at all. Their journey remains uninterrupted. Only when the system detects highly suspicious activity is a challenge presented, so security controls are applied where the risk justifies the friction. For sites that depend on checkout completion, account protection, or lead capture, that is a better trade-off than showing every user another puzzle.

Key Considerations for Effective Bot Management

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

Introduction

Bots account for a large share of web traffic. Recent studies estimate that nearly 50% of all internet traffic is generated by automated programs. Some bots are necessary for the web to function, such as search engine crawlers, but a significant portion are malicious. These "bad bots" are used for content scraping, credential stuffing, spam, and DDoS attacks.

As bot operators become more sophisticated, bot management needs to cover detection, classification, and response. This article outlines the main considerations for security teams protecting intellectual property, online revenue, and user accounts.

The Goal: Accurate Bot Detection and Classification

The first step in effective bot management is separating legitimate users from automated threats. Identification is not enough on its own. Security teams also need accurate classification across good, bad, and "grey" bots.

Good Bots: Support normal internet operations, such as search engine crawlers (Googlebot, Bingbot) and performance monitoring bots.
Bad Bots: Carry out malicious activity such as content scraping, account takeover, and spamming.
Grey Bots: Serve a legitimate purpose but can cause problems when they crawl too aggressively, such as SEO and marketing bots (Ahrefs, SEMrush).

Effective detection usually needs more than basic signatures. A layered approach commonly includes:

Basic Protection: Targets simple bots using user agent checks and IP reputation databases.
Intermediate Protection: Uses JavaScript-based challenges and basic network fingerprinting, such as JA3/JA4, to detect less sophisticated bots.
Advanced Protection: Combines comprehensive network fingerprinting, behavioural analysis, and machine learning to identify sophisticated bots that mimic human behaviour, use residential proxies, or rely on anti-detect browsers.

Machine learning models help in this context because they can learn from changing bot strategies and inspect incoming traffic for subtle signs of automation.

The Method: Continuously Adaptive Detection and Response

Bot behaviour changes quickly. Threat actors modify tooling, traffic patterns, and infrastructure to avoid detection, so static defence rules degrade over time. Organisations need detection and response that can adapt as the attack changes.

That means correlating metadata with behavioural factors in real time, then applying the right response for the risk. When a bot attempts account takeover or data scraping, an adaptive response can act immediately to reduce the impact.

Effective adaptive responses include:

Advanced Rate Limiting: Goes beyond simple IP-based limits by grouping requests with more stable identifiers, such as TLS/HTTP2 fingerprints or device characteristics. This helps stop distributed attacks from tools like OpenBullet that rotate through thousands of IP addresses.
Web Application Firewalls (WAF): Provide an important first line of defence by filtering harmful Layer 7 traffic based on predefined rules.
Tarpitting: Slows malicious connections to increase cost and resource consumption for attackers.
Challenges: Traditional visible CAPTCHAs can harm user experience and are often solvable by modern bots. Invisible challenges can verify a legitimate browser environment with less friction.
Alternate Content Serving: Misleads scraping bots by serving alternate or cached content with incorrect information (e.g., higher prices), making their scraped data useless.

The same response process should also feed learning loops, building a repository of bot attack patterns that can train machine learning models and improve accuracy over time.

The Expected Outcomes: A Resilient Security Posture

An adaptive bot management strategy should support several practical outcomes:

Risk Mitigation: Reduce potential financial losses, service disruption, and data breaches associated with malicious bot activity such as credential stuffing, ad fraud, and inventory hoarding.
Improved User Experience: Keep disruption low for genuine users by using invisible challenges and behavioural analysis instead of frustrating CAPTCHAs, which can reduce conversions by up to 40%.
Intellectual Property Protection: Protect valuable content, pricing data, and other intellectual property from unauthorised scraping.
Online Revenue Security: Protect online revenue streams by preventing fraud, inventory scalping, and other malicious activity that targets e-commerce platforms.
Regulatory Compliance: Help organisations meet data protection and privacy regulations with a proactive bot management approach.

Conclusion: Fortifying Against Sophisticated Bots

Modern bot defence depends on accurate detection, precise classification, and adaptive response. Machine learning, comprehensive network fingerprinting, and behavioural analysis all contribute, but they work best as part of a layered control set.

With that approach, security teams can better protect intellectual property, online revenue, and user accounts from sophisticated bot activity.

The Bot Spectrum

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

The word "bot" is often used as shorthand for unwanted automation: scripts trying to break into accounts, scrape content, or overwhelm websites. A large share of internet traffic does come from bad bots, but automated traffic is not automatically harmful. Some bots are part of how the web is discovered, monitored, and kept usable.

Effective bot management is not about blocking every automated request. It depends on accurate classification: separating good bots from bad bots, and recognising the "grey" bots that sit between them. That classification lets you apply controls that reduce risk without cutting off traffic that helps your site operate.

Good Bots: The Essential Workers of the Web

Good bots are automated programs that perform useful or necessary tasks. They are usually clear about who they are and respect the rules you set in your robots.txt file. Blocking them can damage search visibility, monitoring, or other business workflows.

Examples of Good Bots:

Search Engine Crawlers: Bots like Googlebot and Bingbot are the best-known good bots. They crawl and index your website's content, which is how your pages appear in search engine results. Blocking them would make your site invisible on Google.
Performance Monitoring Bots: These bots are used by services to check your website's uptime and performance from different locations around the world, and to alert you if your site goes down.
Copyright Bots: These bots scan the web for plagiarised content, helping to protect your intellectual property.

Management Strategy: Good bots should be identified and allowed to access your site freely. Verification techniques, such as reverse DNS lookups, can be used to confirm that a bot claiming to be Googlebot is actually coming from Google.

Bad Bots: The Malicious Actors

Bad bots are designed for malicious activity. They are a major reason bot management exists as a security function. These bots are deceptive, often hiding their identity and purpose, and they can be responsible for a wide range of costly and damaging activity.

Examples of Bad Bots:

Credential Stuffers: These bots use stolen usernames and passwords to carry out account takeover attacks.
Content and Price Scrapers: These bots steal your valuable content, product listings, and pricing data, often for use by competitors.
Spam Bots: These bots flood comment sections, forums, and contact forms with unwanted ads or malicious links.
Denial of Service (DDoS) Bots: These bots are part of a botnet used to overwhelm a website with traffic, causing it to slow down or crash.
Inventory Hoarding Bots: Common in e-commerce, these bots automatically add limited-edition products to shopping carts to prevent legitimate customers from buying them, often for resale at a higher price (scalping).

Management Strategy: Bad bots need to be accurately identified and blocked as quickly as possible, ideally at the network edge before they consume your server resources.

Grey Bots: The Nuanced Category

Grey bots are not inherently malicious, but their behaviour can still cause problems. They often serve a legitimate purpose, but become an issue when they crawl too aggressively, consume excessive bandwidth or server resources, and slow the site down for real users.

Examples of Grey Bots:

Aggressive SEO Tools: Bots from marketing tools like Ahrefs, SEMrush, and Majestic crawl websites to gather data for backlink analysis and competitive research. They can be useful, but their crawling can also be heavy.
Partner and Aggregator Bots: These could be bots from partner companies or price comparison websites that need to access your data. The activity may be legitimate, but it still needs to be managed.
Feed Fetchers: Bots that collect data for news aggregators or other applications fall into this category.

Management Strategy: Grey bots require more than a simple allow or block rule. The best strategy is often to rate-limit or tarpit them.

Rate-Limiting: This allows the bot to continue accessing your site, but slows it to a manageable level so it does not overwhelm your servers.
Tarpitting: This intentionally slows the connection for a specific bot, increasing the cost and time required to crawl your site and discouraging overly aggressive behaviour.

By classifying incoming bot traffic and applying the right control for each category, organisations can block threats, manage resource consumption, and allow the useful automation the modern web depends on.

How to Use Bot Management for IAM Use Cases

2025-08-20T00:00:00+10:00

Automated attacks against identity and access management (IAM) systems are now a routine account protection problem. Malicious bots drive account takeovers (ATO), credential stuffing, brute-force login attempts, and fake account creation. As these attacks adapt, traditional IAM controls such as password policies and even multi-factor authentication (MFA) are not enough on their own.

Identity and access management leaders should treat bot management as part of the IAM control set, not a separate website security add-on. A dedicated capability helps reduce avoidable financial and reputational losses from account compromise. It also gives organisations a way to manage the risks created as AI agents become regular users of web applications and APIs.

Introduction

Some estimates suggest nearly half of all traffic is automated. That mix matters: useful crawlers and monitoring tools are part of normal internet traffic, but malicious automation is built to test web applications at scale. IAM systems, which control access to sensitive user accounts and data, are a primary target.

The most common bot attacks targeting IAM include:

Credential Stuffing: Attackers use lists of stolen usernames and passwords from third-party data breaches to gain unauthorised access to user accounts. This attack vector is effective because password reuse is still common.
Brute-Force Attacks: Automated scripts guess passwords for known usernames, often targeting login endpoints for platforms like WordPress and Magento.
Fake Account Creation: Bots create fraudulent accounts at scale, which can be used for spam, malware distribution, or to abuse promotional offers.

Recent attacks on major Australian retailers like The Iconic and Dan Murphy's show the practical impact. These incidents, driven by credential stuffing, resulted in reputational damage and financial loss, forcing the companies to issue refunds and publicly address security concerns.

Analysis

Defending IAM systems starts with why common controls fall short and where bot management adds useful signal.

Why Traditional IAM Defences Fail

Attackers have adapted their techniques to bypass legacy security controls. Simple IP-based rate limiting and reputation lists struggle against the combination of residential proxies and anti-detect browsers:

Residential Proxies: Attackers route their traffic through large networks of IP addresses belonging to real residential internet connections. This makes malicious traffic appear legitimate and allows attackers to bypass IP-based blocking and geolocation restrictions. Our own tests show that even leading IP intelligence services fail to detect the vast majority of residential proxy traffic.
Anti-Detect Browsers: These specialised browsers allow attackers to spoof their digital fingerprints, mimicking legitimate user devices and browser configurations. This weakens many JavaScript-based challenges and fingerprinting techniques.

Used with automation suites like OpenBullet, these tools let attackers run "low and slow" distributed attacks that blend into normal traffic. For more information on these tools, see our guide to enterprise bot management.

The Flawed Logic of CAPTCHA

For years, CAPTCHA has been the default way to distinguish humans from bots. It is now a weak control when used on its own. Our research shows that visible CAPTCHAs have a severe negative impact on user experience and conversions. Studies have found that CAPTCHAs can reduce form conversions by up to 40%, as frustrated users abandon purchases or sign-ups.

Modern bots can also solve CAPTCHAs with high accuracy, often more effectively than humans, by using CAPTCHA-solving farm services. Relying on CAPTCHA alone creates friction for legitimate users while providing a false sense of security. Modern bot management uses invisible challenges and behavioural analysis to validate users without disrupting their session.

Modern Bot Management Capabilities for IAM

An effective bot management solution provides a multi-layered defence that goes beyond simple signatures. Key capabilities include:

Advanced Rate Limiting: Instead of relying on IP addresses, modern solutions group requests using more stable identifiers like TLS/HTTP2 fingerprints, device characteristics, or a combination of headers. This helps detect distributed attacks from a single malicious tool, even as it rotates through thousands of IPs.
Network and Device Fingerprinting: By analysing the unique characteristics of a client's TCP and TLS implementation, it is possible to identify the underlying software making the request, regardless of the user-agent header. This helps distinguish between real browsers and automated scripts.
Behavioural Analysis: Systems can model normal user behaviour—such as mouse movements, typing speed, and page navigation—to identify anomalies that indicate automation.
Residential Proxy Detection: Specialised techniques are required to identify traffic coming from residential proxy networks, which is a strong indicator of malicious intent.
Breached Credential Integration: By checking login attempts against databases of known breached credentials, security teams can apply additional scrutiny to high-risk authentication events.

Together, these controls give IAM teams more useful decision points than an IP address, a password check, or a CAPTCHA challenge alone.

The Next Frontier

The next major change in automated traffic is agentic AI. As reasoning models like DeepSeek become more accessible, we are entering an era where AI agents are becoming primary consumers of APIs and web applications.

These are not just the rigid scripts of the past. AI agents can reason, plan, and adapt their behaviour in real-time based on a system's responses. They can analyse an entire API surface in seconds and generate complex interaction patterns that human developers would be unlikely to try manually.

This creates a harder IAM problem. Bot management has usually looked for patterns that differ from normal human behaviour. AI agents can make those patterns less reliable by imitating user behaviour while still operating at machine speed. The line between human and automated traffic blurs.

IAM leaders need bot management solutions that can adapt to this shift. The future of bot management will not only be about blocking bots; it will also be about deciding which automated agents are acceptable, under what conditions, and with which controls. This requires a shift from static, rule-based security to contextual analysis that understands and adapts to agent behaviour, distinguishing between legitimate AI assistants and malicious ones. Organisations that wait until agent traffic is common will have less time to distinguish useful automation from AI-driven attacks.

The Negative Impact of Visible CAPTCHAs on Bounce Rates and Conversions

2025-08-06T13:00:00+10:00

A client of Peakhour's recently migrated their site to us from a bot management vendor that used visible CAPTCHAs. After the migration they noticed double-digit year-on-year growth in revenue and conversions. We'd like to take the credit, but there is a simpler explanation: our bot management works differently. We use targeted invisible challenges to verify browser environments rather than visible CAPTCHAs. Could that account for such a large difference? I decided to check what the research says.

Visible CAPTCHAs (like image-selection or text puzzles) are still a common way to separate humans from automated traffic. They can block some bots, but they also add friction for legitimate users. Recent analyses across providers, including Human (formerly PerimeterX), Google’s reCAPTCHA, Arkose Labs, and others, point to measurable impacts on ecommerce performance and customer behaviour.

Conversion Rate Impacts of Visible CAPTCHAs

Multiple studies and vendor reports show that visible CAPTCHAs can substantially reduce conversion rates. A Stanford University study found that a CAPTCHA challenge can reduce form conversions by up to 40%. In practical terms, many users abandon signup or checkout forms when they hit a CAPTCHA. HUMAN Security researchers similarly found that 40% of real human shoppers have given up on a purchase due to CAPTCHA frustration. For an online retailer, losing up to 40% of potential sales at the final hurdle is a direct revenue problem. Forrester Research reported 19% of consumers have abandoned a website entirely because of encountering a CAPTCHA – showing how these challenges can drive users away before conversion.

Even smaller conversion drops matter. One bot mitigation firm (Datadome) observed that adding a CAPTCHA to a site led to a 3.2% higher bounce rate and an overall 3–5% drop in conversion. Given that average e-commerce conversion rates are often just 2–3%, losing even a few more percent of customers can materially affect revenue. In industries with thin margins and high customer acquisition costs, no business wants to sacrifice those would-be buyers.

Bounce Rates and User Abandonment

Every extra step in the user journey increases the risk of bounce (users leaving after a single page). CAPTCHAs are a common cause. Studies show about 30% of users will leave a site if a CAPTCHA is too complex or cumbersome. Long or indecipherable challenges cause users to give up, raising bounce rates. In one example, shoppers who faced repeated CAPTCHA puzzles during checkout simply exited, contributing to higher cart abandonment and bounce metrics. Even users who intend to buy may get frustrated by being treated like “bots” and decide the purchase is not worth the hassle.

Online patience is thin. Customers expect quick transactions, especially on mobile devices. CAPTCHAs slow things down: one analysis noted completing actions on mobile takes 30–40% more time with a CAPTCHA than without. That delay is enough to hurt conversion, as hurried mobile users are quick to drop off. As a result, visible CAPTCHAs often correlate with higher bounce rates and shorter time-on-site, indicating that challenged users are abandoning sessions. Some reports estimate 20% of users will leave if they encounter difficulties solving a CAPTCHA. This abandonment directly translates to lost sales or sign-ups.

User Experience Friction and Qualitative Insights

Qualitatively, visible CAPTCHAs introduce real user experience (UX) friction. Usability experts note that CAPTCHAs are often hard to read, carry no real meaning for the user, and feel like an unnecessary test, all of which irritate customers and “kill” conversions. They can be especially off-putting to certain user segments, such as older users or those with disabilities. For example, visually impaired users may find image CAPTCHAs nearly impossible to complete, leading to exclusion and site abandonment (W3C Accessibility Guidelines). Legitimate customers often feel inconvenienced or even insulted by being forced to “prove” they are human. As one industry commentator quipped, “Every CAPTCHA is a time tariff imposed on your customers” – it is a tax on their time and patience, which benefits nobody in terms of sales.

False positives (human users being mistaken for bots) make this worse. If a security system is too sensitive and throws frequent CAPTCHAs at real shoppers, it creates friction without benefit. Users confronted with multiple challenges may think twice about continuing. DataDome’s research notes that excessive CAPTCHA usage causes a suboptimal experience, and customers have “little patience” for such delays. The result can be reputational damage as well – annoyed users might complain publicly, hurting the brand. In short, traditional CAPTCHAs tend to “treat customers like criminals”, which pushes people away.

Industry-Specific Observations

The negative effects of visible CAPTCHAs show up across industries, with different tolerance for security friction:

Retail & E-Commerce: Online retail (from fashion to electronics) is highly sensitive to checkout friction. Shoppers have many alternatives, so a challenging CAPTCHA can send them to a competitor’s site in seconds. Even one extra step can hurt sales conversion. E-commerce case studies consistently show that removing CAPTCHAs boosts conversions. Bot solution vendors note that losses from CAPTCHA friction are “especially noticeable in areas such as e-commerce” where even a 3–5% conversion dip means thousands of customers lost.
Travel & Ticketing: Travel sites (flights, hotels) and ticketing platforms often deploy CAPTCHAs to thwart scalpers and bots (e.g. for popular concert tickets or holiday bookings). That can protect inventory, but it can also turn away real customers. Travellers shopping around for deals won’t hesitate to bounce if a booking site throws up hurdles – they’ll try another site. Travel bookings are often time-sensitive (flash sales, limited seats), so any slowdown from a puzzle challenge can cause users to miss out and blame the site. The challenge for this sector is to weed out bot traffic (which can be a huge share of ticketing traffic) without derailing genuine user transactions. Some travel companies use alternatives like virtual waiting rooms or invisible challenges to reduce user-facing friction. A smooth booking path matters: industry observers emphasise that travel and hospitality businesses that “remove booking friction” are rewarded with higher conversion and direct revenue, whereas those using blunt CAPTCHA challenges risk higher bounce rates and lost bookings.
Finance & Banking: Financial services websites (online banking, fintech apps, etc.) deal with sensitive transactions and may introduce verification steps (CAPTCHAs or multi-factor authentication) for security. Users in this sector can be slightly more tolerant of friction if it clearly signals security. However, if a bank’s CAPTCHA fails normal users or frequently interrupts login, customers will get frustrated or call support. Financial institutions must balance fraud prevention with a smooth experience – if there is too much friction, users may abandon opening an account or using the service. In fact, the same 40% conversion drop risk applies here: lost applications or completed transactions if security measures are overbearing. So even in finance, the trend is toward smarter, invisible verification methods to minimise extra steps.
Other Industries: Nearly any consumer-facing online service – from gaming and streaming to government portals – faces the CAPTCHA UX dilemma. Users expect minimal friction. In some niches (e.g. gaming), users are extremely averse to any interruptions in sign-up or sign-in. In others (like online voting or government forms), a CAPTCHA might be more accepted, but if it fails or confuses users, it can prevent task completion. The pattern is consistent: user expectations for convenience are high across the board, and visible CAPTCHAs risk alienating users in any vertical if not handled carefully.

Death of the CAPTCHA

Visible CAPTCHAs are still widely used, and they still add friction at critical moments. The research above shows users often abandon sites or carts rather than struggle with puzzles – a loss of sales that can range from a few percent to double digits. This effect is seen broadly, from fashion retail to travel bookings to financial services.

That is before we consider the actual effectiveness of visible CAPTCHAs. Other studies have shown bots can be MORE effective than humans at solving them.

That is why Peakhour uses invisible challenges: verify the browser environment without making legitimate customers solve a puzzle.

Protecting Against a Share Point Zero Day Vulnerability with Network Fingerprinting

2025-07-23T13:00:00+10:00

Why Network Fingerprinting is Your Strongest First Defense

A critical new remote code execution (RCE) vulnerability in on-premises Microsoft SharePoint Server, identified as CVE-2025-53770, is being actively exploited and presents a serious risk to organisations. This flaw allows an unauthenticated attacker to take complete control of a server over the network, so immediate and effective defence is a priority. Microsoft disclosed the flaw on 19 July.

Vendor patches are essential, but zero-day activity often starts before most organisations can patch. That gap is where proactive controls matter.

This post looks at the technical nature of this threat and how a strategy centred on network fingerprinting can block zero-day exploit activity before a formal patch is deployed.

Understanding the Threat: CVE-2025-53770

The SharePoint vulnerability is particularly dangerous as it allows for the deserialization of untrusted data, leading to remote code execution without any need for attacker authentication. This makes any unpatched, internet-facing on-premises SharePoint server a potential target. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has underlined the severity of this threat by adding it to its Known Exploited Vulnerabilities Catalog.

Exploitation can lead to a complete compromise of the SharePoint server, allowing attackers to steal data, execute arbitrary code, and potentially move laterally across the internal network.

The Race Against Scanners

When a zero-day vulnerability like this is discovered, a global, automated race begins. Malicious actors immediately deploy scanners to canvass the internet for vulnerable systems.

Our own analysis shows that the majority of malicious requests targeting our clients came from the DigitalOcean and Scaleway ASNs, with Amazon Web Services (AWS) EC2 and Microsoft Azure also being a prominent source. These networks are well-known for being used by malicious actors to launch scanning and attack campaigns quickly. Notably, scans were happening on 16 and 17 July, before the vulnerability was disclosed by Microsoft.

This initial scanning phase, however, creates an opportunity for defence. Instead of waiting to analyse the specific attack payload, we can identify and block the very tools the attackers are using.

Exploits attempts in the wild. Note attempts days before disclosure.

Why IP Reputation Isn't Enough

For years, a primary method of defence has been IP reputation—blocking traffic from IP addresses known to be malicious. While simple and somewhat effective against basic attacks, this approach is increasingly unreliable in the face of modern threats.

The rise of sophisticated proxy services has changed the model. Attackers now have easy access to vast networks of residential, mobile, and rotating data centre proxies. These services allow them to distribute their attack traffic across thousands or even millions of seemingly legitimate IP addresses, making it impossible to maintain an effective blocklist. An IP that sends a malicious request one moment could be used by a legitimate customer the next.

Furthermore, attackers leveraging cloud infrastructure use ephemeral IPs that exist for only a short time, rendering IP-based blocking a constant and losing game of cat and mouse. This approach also carries a high risk of "collateral damage", where legitimate users are blocked simply because they share an IP address with a bad actor, a common scenario with Carrier-Grade NAT (CGNAT) or public Wi-Fi. Relying solely on where a request comes from is no longer a viable strategy.

Unmasking the Attacker's Tools with Network Fingerprinting

This is where network fingerprinting becomes useful as a zero-day defence. Fingerprinting in cybersecurity refers to methods used to identify the unique characteristics of devices, software, or users. It allows for the identification and categorisation of operating systems and software based on their distinct signatures in network communications.

When attackers rush to exploit a new vulnerability, they don't use standard web browsers. They quickly code scanners using programming languages and libraries like Python, Go, or Java. These tools and libraries create network connections with distinct, non-browser-like fingerprints. By analysing these, we can block the scanner before it ever delivers its malicious payload.

Peakhour uses several passive fingerprinting techniques to do this:

TCP Fingerprinting

This method identifies a device's operating system by analysing how it implements the TCP protocol. By examining nuances in TCP packets—like window size, Time to Live (TTL), and how the device responds to non-standard packets—we can identify the underlying system that created the request.

TLS Fingerprinting

This technique analyses the "ClientHello" message sent by the client during the initial TLS handshake to establish a secure connection. The combination of TLS version, supported cipher suites, and extensions creates a unique fingerprint. This is a highly effective way of identifying the classes of connecting clients, such as those made by Go, Python, or Java libraries, which are commonly used for attack tooling. JA4 and JA3 are popular TLS fingerprint formats.

HTTP/2 Fingerprinting

This involves analysing how clients use the HTTP/2 protocol, including their patterns in sending HTTP/2 frames and negotiating connections. This makes it easier to differentiate between legitimate browsers, bots, and the custom applications used in an attack campaign.

After identifying these fingerprints, Peakhour's bot management service uses machine learning to classify them as either a legitimate browser or a bot. This provides a strong layer of defence against zero-day exploits. The scanners are identified and blocked based on their fundamental network characteristics, irrespective of the specific vulnerability or payload they carry.

Defense in Depth

No single security measure is a silver bullet. While network fingerprinting provides a powerful first line of defence against automated scanners, a multi-layered, defence-in-depth strategy matters.

Any request that manages to bypass the initial fingerprinting checks must face the next layer: our standard Web Application Firewall (WAF) with post-body scanning. A WAF inspects every request before it reaches the application. By enabling the inspection of the full request body, the WAF can identify and block malicious payloads, such as the specific code used in an exploit attempt, that may be hidden within the data sent to the server. Our WAF was updated with a virtual patch on 22 July at 5am AEST to add protection against this vulnerability.

Staying Ahead in a Zero-Day World

The SharePoint CVE-2025-53770 vulnerability shows why a reactive security posture is not enough. While patching is essential, the reality is that attackers move first.

By using proactive techniques like network fingerprinting, organisations can identify and neutralise the automated tools attackers rely on during the critical opening hours of a zero-day exploit's life. This approach, when combined with payload inspection from a WAF, gives critical assets another layer of practical protection.

Why Don't We Have an AI UI Yet?

2025-07-20T00:00:00+10:00

In my last post, I made the case that Artificial Intelligence is the next great computer interface: a way to translate our intentions directly into actions. It is a powerful idea, but it immediately raises the practical question. If this is the future, where is it? Why am I still clicking icons and navigating menus on my computer instead of just talking to it?

The concept is much cleaner than the implementation. We are still a fair way from having a true AI-native interface, and there are some hard problems to solve before it becomes the main way we use a computer.

The Understanding Problem

The first challenge is that current AIs don't truly understand things in the way humans do. When you ask an AI to "write a summary of last quarter's sales," it doesn't know what a "sale" is or what a "quarter" means to the business. It is an extremely capable pattern-matching machine that knows which words and concepts are statistically likely to follow your request.

That is useful for generating text or code, but it can also lead to "hallucinations"—where the AI confidently makes things up. For a chatbot, that might be annoying. For a computer's operating system, it is a critical failure. You can't have an interface that might invent a file that doesn't exist or misinterpret a crucial command.

The Action and Safety Problem

An AI interface needs to do more than just talk; it needs to act. It must be able to open programs, manage files, change settings, and send emails. That requires giving the AI deep access to the core functions of the operating system, which is where the idea stops feeling neat and starts feeling risky.

How do you give an AI the power to delete files based on a verbal command without creating a massive security hole? How do you ensure it can't be tricked by a cleverly worded prompt (or an external attacker) into causing chaos on your system? Creating a safe and reliable bridge between the AI's language processing and the computer's functions is a hard engineering problem.

The Trust and Reliability Problem

For an AI interface to be useful, we have to trust it completely. If you tell it to "delete my old holiday photos from 2018," you need to be certain it won't misunderstand and delete your wedding photos or important work documents.

This need for absolute reliability runs counter to the probabilistic nature of today's AI models. We can't have an interface that is "mostly right." It needs to be right every single time. The hard part is adding the necessary safeguards and confirmation steps without turning the whole thing into a slower version of the menus we were trying to escape.

The Speed and Cost Problem

Finally, there is a practical issue. Running the massive language models that would power such an interface is slow and computationally expensive. A good user interface needs to feel instant and responsive. If it takes ten seconds for an AI to process your request to open a web browser, it is not a better experience than just clicking the icon yourself. The hardware and software infrastructure isn't quite ready to deliver the seamless, real-time experience we would expect from a primary computer interface.

These challenges aren't insurmountable, but they are significant. That is why I think AI will keep showing up first as powerful features within our existing apps and operating systems. Those narrower uses give it clearer jobs, tighter permissions, and more places for humans to confirm what is about to happen. The full AI interface may arrive eventually, but I don't think it appears all at once. It will earn trust in smaller pieces first.

AI as the Translator Between Human and Machine

2025-07-19T00:00:00+10:00

Think about how we've talked to computers over the years. At first, it was rigid and unforgiving. The command line expected the exact words, in the exact order. One typo, and you were met with an error. It was powerful, but only once you learned to speak the computer's language.

Then came the graphical user interface, or GUI—the familiar world of windows, icons, and mouse pointers. That changed the relationship. You no longer had to memorise commands before you could do something useful. You could see your options, click on them, and drag things around. It made computers accessible to hundreds of millions of people because it was more intuitive. It was a visual conversation.

But both of these interfaces, the command line and the GUI, share the same basic bargain: we adapt ourselves to the computer. We still have to navigate menus, find the right button, or remember a specific command. We take a goal in our head and break it into steps the computer understands.

What if that translation was no longer mainly our job? What if the computer could understand our goal well enough to work out the steps?

This is the next shift I find interesting, and it is powered by Artificial Intelligence. AI is starting to look less like another application and more like the next major interface. It's not a visual one with buttons and menus, but an intelligent one built on understanding.

The idea is simple, even if the implementation is not: we state our intent, and the AI figures out the steps. Instead of clicking through five different menus to create a sales report, you could just say, "Show me last quarter's sales figures for the eastern region, and visualise it as a bar chart." The AI's job is to understand that request and then do the work: query the database, aggregate the data, select the right chart type, and present it to you. It acts as a translator between human language and the computer's machine language.

We're already seeing the early stages of this. When you ask a smart assistant to play a song, or when an AI co-pilot writes code for you, you're using an intent-driven interface. You're not telling it how to do the task; you're just telling it what you want done.

That shift matters because it moves some of the cognitive load from us to the machine. We no longer need to be experts in using a particular piece of software; we just need to be clear about what we want to achieve. This has the potential to democratise technology on a scale we've never seen before, making complex digital tools feel closer to a conversation than a training course.

The future of computing isn't about learning more complex systems. It's about building systems that can learn from us. The interface of tomorrow won't be something we click on, but something we talk to, correct, and steer. That is the real change: technology that doesn't just follow instructions, but understands our goals.

From Research Paper to Running Code

2025-07-18T00:00:00+10:00

In my last post, I talked about my journey from typing format c: on an old DOS machine to collaborating with AI. The part I keep coming back to still feels slightly unreal: turning academic research papers directly into working code.

For years, the hard part was the distance between academia and industry. A good idea could be locked inside a dense, equation-heavy paper, and turning it into a practical tool could take a team of specialists weeks or months. You had to understand the mathematics, translate it into logic, write the code, and then debug all the places where the theory met the real world.

Now my process looks completely different. I'll find an interesting paper, give it to an AI like Gemini, and say, "code this for me". It is a conversation, not just a command. We go back and forth, clarifying ambiguities in the paper and refining the implementation. What used to take weeks of painstaking effort can now be prototyped in an afternoon.

Here are a few examples from my own experiments.

Anomaly Detection

I recently came across a paper detailing a new statistical method for detecting anomalies in time-series data. In the past, I would have spent days just trying to get comfortable with the mathematical models before writing a single line of code. This time, I fed the PDF to the AI. Within minutes, it had parsed the document and produced a Python implementation of the core algorithm. It was not perfect on the first go, but it was a solid, working foundation that we could test and refine together. The AI handled the heavy lifting of translation, leaving me to focus on validating and applying the model.

Customer Journey Mapping

Another area I have been looking at is using data to understand customer behaviour. There are academic papers that model how users interact with a website or product, mapping out their journey from discovery to purchase. Implementing these models used to be a serious undertaking. Now, I can give the AI a paper on a new journey mapping technique, and it can generate the code to analyse server logs or user event data and produce the kind of insights the paper describes. That makes it much easier to experiment with new ways of understanding our customers.

Building Small Language Models

This is where it gets really interesting. We can use large language models (LLMs) to help build smaller, more specialised ones. I've been experimenting with research papers that propose new, efficient LLM architectures. I can give one of these papers to a large AI and have it help me write the code for the smaller architecture. There is a beautiful irony in using a massive AI to help create its smaller, more nimble cousins. It speeds up the cycle of innovation inside the AI field itself.

For me, the important change is the shorter loop between reading an idea, testing it, and getting it into use. The friction between a theoretical concept and a working prototype has been reduced almost to zero. That means I can explore more ideas, take more risks, and bring those research ideas into real use much faster than before.

My Programming Journey

2025-07-17T00:00:00+10:00

My path into technology started with a beige box and no plan beyond seeing what it would do.

When I was a kid, I got an old 8086 computer. The only thing it came with was a thick manual for 'DOS', its operating system. For a child trying to make sense of it, the blinking C:\> prompt was not exactly welcoming. What was I meant to do with it?

I tried typing whatever came to mind, but most of it ended in errors. Then I stumbled on a command that actually did something interesting: format c:. After I typed 'Y' to confirm, the screen would fill with text, showing me its progress. I didn't realise I was wiping the computer's entire memory. I only knew the machine was finally responding.

Things properly opened up when I found a book filled with GW-BASIC programs. I wasn't just using a computer anymore; I was telling it what to do. I spent ages carefully typing out code, one line at a time. 10 PRINT "HELLO THERE", 20 GOTO 10. It was slow work, but there was something hard to beat about bringing a program to life with my own hands.

My skills moved along when QuickBasic started coming with MS-DOS. The tools were better, the language was more powerful, and I started building my own little games and applications, learning how to organise my ideas into code.

Every programmer eventually hits a wall. For me, it was a 64-kilobyte limit on a single variable. It sounds tiny now, but it blocked a project I cared about. The only way forward was to learn C, a much more complex language. It was a hard jump, but it was the way to build bigger and more powerful software.

That arc is why today's tools feel so strange to me.

For most of my career, my job was to translate human ideas into instructions a computer could follow. I had to think like a machine, breaking everything down into small, logical steps.

Now the process feels very different. I still solve problems, but I spend less time spelling out every instruction. I have a conversation with my computer. I can describe a goal, or show it a research paper, and an AI partner helps me write the code. My role has shifted from writing each line by hand to setting direction, checking the work, and deciding what is actually worth building.

Looking back, the path from blindly typing format c: to working alongside an AI still feels odd in the best way. We've moved from telling the machine exactly how to do something to describing what we want to achieve and then judging the result. That is a big change. I am still getting used to it.

SMS Pumping Fraud: How Verification Traffic Inflates the Bill

2025-03-13T14:00:00+11:00

The Growth of SMS Fraud

SMS pumping fraud is a costly online abuse pattern, with global losses reaching an estimated $6.7 billion in 2021 alone. It targets companies that rely on SMS for verification or customer communications, leaving them to pay for traffic they did not request.

The scheme relies on malicious actors and dishonest telecom operators working together to generate and monetise large volumes of fraudulent text messages. For businesses caught in these schemes, the financial impact can be severe. Twitter (now X) reportedly lost $60 million to this type of fraud.

This guide explains how SMS pumping works, which businesses face the highest risk, and the controls your organisation can use to reduce exposure.

Understanding SMS Pumping Fraud

SMS pumping (also called SMS toll fraud, SMS spamming, or Artificially Inflated Traffic) involves manipulating mobile networks to inflate charges for text messages. The term "pumping" describes fraudsters forcing high SMS volume through a target's systems.

This fraud exploits how SMS messages travel and get billed across phone networks. Attackers target companies that use SMS codes to verify users. Each time a business sends a verification code, it pays a fee. Fraudsters trigger these systems to send thousands of messages to numbers they control.

These attacks create direct costs for businesses and revenue for the attackers. The fraud works through coordination between criminals and corrupt telecom operators, who charge premium rates for message delivery and share the proceeds.

The fraud has changed as more businesses have adopted SMS verification. Attackers keep developing new methods, and the phone industry has not removed the risk. Many companies still carry the financial exposure.

How SMS Pumping Works

SMS pumping attacks usually exploit message systems through these steps:

Finding Targets: Attackers look for websites or apps that send SMS codes for account verification or password resets.
Creating Fake Requests: Fraudsters use automation to send thousands of code requests to phone numbers they own or control.
Hiding Their Tracks: Attackers change their IP addresses and device information so requests appear to come from real users.
Sharing Profits: Fraudsters work with dishonest phone companies that charge high fees when messages pass through their networks. These companies then share the money with the attackers.
Using Complex Routes: Messages travel through many networks before reaching their destination, making the source of the fraud harder to trace.
Targeting Expensive Routes: Attackers focus on international numbers where sending messages costs more or where rules are weaker.

These attacks look legitimate because each message contains a real code sent to what appears to be a normal phone number. Companies like Twilio or Bird must pay fees to deliver these messages. Most businesses only find out about the fraud when a large bill arrives from their SMS service.

SMS pumping differs from basic spam because the profit-sharing between attackers and phone companies creates a direct cost for the target business.

Businesses at Risk

SMS pumping is most likely to affect these types of businesses:

Financial Institutions

Banks, investment platforms, and cryptocurrency exchanges use SMS codes to protect accounts. These firms send thousands of codes each day, which makes it hard to spot fake requests mixed with real ones.

E-commerce Platforms

Online shops use SMS messages when users create accounts, reset passwords, or make purchases. These businesses often run on small profit margins, so extra SMS costs can hurt their earnings. High volumes of new users make it easier for attackers to hide their activity.

Social Media Companies

Social networks use text messages to check user identity and stop fake accounts. These companies send millions of codes each day to users around the world. Twitter lost $60 million from this type of fraud, showing the scale these bills can reach.

Software-as-a-Service (SaaS) Providers

These companies often offer free trials that require SMS verification. They plan for a set cost to acquire each new user, but fraud can push these costs much higher than expected.

Telecommunications Companies

Phone companies face two problems: their own systems can be attacked, and parts of their network might help fraudsters. They need strong monitoring tools to find unusual patterns in message traffic.

Small Businesses and Startups

While smaller firms send fewer messages, they often lack security teams and fraud detection tools. This makes them easier targets. The cost of an attack can put these businesses at risk of closing down because they have less money in reserve.

Advanced Attack Methods

Attackers now combine SMS pumping with other techniques to avoid detection.

Credential Stuffing

Fraudsters use passwords stolen in data breaches to break into accounts. Once inside, they change phone numbers to ones they control and trigger verification messages. This makes fraud appear to come from real users.

Peakhour's breach database detection identifies when stolen credentials are used to access accounts. The system flags these attempts before phone numbers can be changed, stopping the attack chain.

Residential Proxy Networks

Unlike data centre proxies that security systems can often spot, residential proxies hide attack traffic behind home internet connections. This makes fraud look like it comes from regular users in different locations.

Peakhour specialises in residential proxy detection. Its technology identifies these masked connections and blocks them before verification requests can pass through. The system maps known proxy networks and detects signs of traffic passing through residential IPs.

When combined with device fingerprinting, these protections create a stronger defence. Fingerprinting tracks device characteristics that remain consistent even when attackers change IP addresses or accounts. Peakhour's fingerprinting technology works without cookies, making it effective against attackers who clear browser data.

These methods focus on the techniques fraudsters use to hide their identity. With Peakhour's protection, businesses can detect and block these attacks before they trigger costly SMS verification messages.

Historical Incidents

Reported SMS pumping incidents show how quickly costs can build:

Twitter's $60 Million Loss

In January 2023, Twitter owner Elon Musk said the platform lost more than $60 million to SMS pumping fraud. He named over 390 phone companies that took part in the scheme. While Twitter later questioned some claims, the case brought public attention to this type of fraud.

Industry-Wide Financial Impact

The Communications Fraud Control Association reports that SMS pumping caused global losses of $6.7 billion in 2021. Many companies do not share their fraud losses with the public.

Costs to Individual Businesses

Companies hit by these attacks pay between tens of thousands and millions of dollars each month in fake charges. These costs grow fast because each fake message costs much more than normal text rates.

Verification Policy Changes

Because of these threats, many large platforms have moved away from SMS codes. Twitter removed SMS verification for most users in March 2023, stating fraud as the reason.

Operational Disruptions

Beyond the cost of messages, businesses can face service problems during attacks. Real users may not get their codes on time. This can cause users to abandon transactions, contact support more often, and lose confidence in the company.

Rules and Enforcement

Rules to stop these attacks differ around the world. Some telecoms authorities have strict rules and fines for networks that allow fraud, but enforcement remains hard. Fraudsters use complex message routes that cross many countries to avoid getting caught.

Understanding the Stakeholders

SMS pumping involves these key groups:

Businesses

Companies use SMS to check user identity and send updates. They hire SMS gateway providers to handle their messages. When fraud happens, these businesses pay for the fake messages. Most find out about the attack only when they receive an unexpected bill.

SMS Gateway Providers

Companies like Twilio and MessageBird connect businesses to phone carriers. They give businesses tools to send text messages without working with phone networks directly. When fraud passes through their systems, these providers may try to stop it, but still charge businesses for the messages sent.

Mobile Network Operators (MNOs)

These companies run the networks that deliver messages to phones. Most work honestly, but SMS pumping schemes often include corrupt operators who charge extra fees for messages to numbers they control. These operators then split the money with the attackers who started the fraud.

Content Aggregators

These middlemen combine message traffic and work with many carriers to find the best routes. Most run honest operations, but their position in the message chain creates routing and oversight gaps that attackers can use.

Regulatory Bodies

Groups like the GSM Association create rules and standards for the industry. These rules are hard to enforce because phone networks cross many countries with different laws.

Financial Flow

The payment flow starts when businesses pay gateway providers to send messages. The gateway providers then pay fees to network operators based on where messages go. In fraud schemes, inflated fees go to corrupt operators who share the money with attackers. This creates a system where sending more fake messages makes more money for criminals while costing honest businesses more.

Effective Protection Strategies

Protecting your organisation usually requires several controls:

Basic Protections

Rate Limits: Restrict how many verification attempts a user can make in a set time period.
Traffic Pattern Checks: Track normal SMS message patterns and watch for changes that might indicate attacks.
Provider Protection: Services like Prelude's SMS Pumping Protection find and block messages to fake numbers.
Other Ways to Verify Users: Use app-based verification or push alerts instead of SMS codes.
Control by Country: Limit SMS verification to countries where you do business and add more checks for countries with higher fraud risk.
Work with Trusted Partners: Choose SMS service providers that focus on security and can help stop fraud quickly.

Advanced Protection Methods

Residential Proxy Detection: Find and block users who hide their true location behind home networks used as proxies.
Device Fingerprinting: Collect device signals to track users across sessions and spot when many verification requests come from the same device.
User Behaviour Tracking: Learn how real users act on your site and flag unusual actions that might be bots.
Machine Learning Systems: Use systems that learn from data to find hidden fraud patterns and adapt to new attack types.
Phone Number Checks: Use lists of known bad numbers to decide which phone numbers need more verification steps.
Verify in Multiple Ways: Ask users to prove who they are in different ways, such as email plus SMS, to make attacks harder.
Work with Other Companies: Share information about new attack methods and bad phone numbers with other businesses.
Watch Transactions as They Happen: Use systems that can pause message sending when they spot unusual patterns and learn from both legitimate and abusive traffic.

Measure the request before the message

The 2021 estimate establishes scale, not your current exposure. Start with your own send records: verification route, country and carrier, account or session, messages per destination, completion rate, provider cost and the time between requests. Join that with the edge decision that allowed the request to reach the SMS provider.

Rate limits should follow the business action, not only the source IP. A practical policy can count by route, destination prefix, account, device or network cohort, then step from logging to delay, challenge or block as confidence increases. Residential proxy and fingerprint signals can add context, but neither proves fraud on its own.

The messaging provider sees another part of the chain. Prelude's fraud controls can evaluate number and route risk while Peakhour controls the web request that initiated the send. Keep both outcomes in the same incident record so the team can tell whether it stopped a fraudulent request, suppressed a legitimate customer or merely moved the cost to another route.

Set a spending alert and an emergency send limit before the first incident. During an attack, preserve the requests, destinations, provider decisions and charges. Afterward, replay legitimate verification journeys and remove temporary blocks that no longer have a defined job.

Why We Can't Trust IP Addresses

2025-03-11T14:00:00+11:00

This article is a dated market snapshot. Product prices, package sizes and vendor quotations reflect what was publicly advertised in March 2025. The enduring security point is that consumer and mobile connectivity can be packaged cheaply enough to weaken IP-only trust.

Blocking bad traffic by checking an IP address used to be a reasonable starting point. It is not enough anymore. The rise of residential proxies, especially mobile proxies like those from Proxidize, has weakened one of the simpler assumptions in web security: that an IP address tells you much about who is behind a request.

Why is this a problem now?

Residential proxies route traffic through real household IP addresses, so requests look as if they come from normal homes rather than data centres. Companies like Proxidize have made mobile proxy setups accessible using Android phones or USB modems.

In my presentations at AISA and other security conferences, I've described these proxies as systems that "masquerade internet usage as originating from residential and office networks," because they sit outside the assumptions used by many security controls.

What has changed recently is access. Proxidize offers kits that let anyone set up a proxy farm - from 5-modem kits at $499 to 80-modem setups for around $6,000. They have turned proxy farming into a plug-and-play system where you can be up and running "in less than 60 seconds."

The scale is large. Proxidize users process an estimated 80 billion records combined every single day: 80B+ Records Scraped Daily.

The model is also being sold as a "passive income opportunity," where people can earn money by setting up proxy farms and selling access to others. In their recent webinar, they announced plans for a "Proxidize Grid" marketplace where users can sell their proxies with "a single click through an automated Marketplace."

The BYOD mobile proxy revolution

Companies like iProxy.online have taken this further with a Bring Your Own Device (BYOD) approach. Rather than requiring specialised hardware, they let customers turn any Android device into a mobile proxy.

As Sabir, the cofounder of iProxy.online, explained in a recent interview, "You can install iProxy app here and in the dashboard you have proxy access like Socks5, HTTP accesses, and traffic goes through your device."

This means anyone with an old Android phone and a SIM card can create their own mobile proxy, lowering the barrier to entry. For around $59 per month (based on Proxidize's pricing), users get access to what Sabir calls "precious" mobile IP addresses.

Why are mobile IPs so valuable? As Sabir explains: "If you have Barcelona, we are here in Barcelona and you have like 2 million people living there and you have like several thousands of IP addresses from your mobile providers. And one IP address is shared by many. By thousands of people... And if you have mobile IP address, this cannot be blocked by Facebook or Instagram or any other services because in this case, like innocent people, like thousands of them will be blocked."

This carrier-grade NAT (CGNAT) technology means mobile IP addresses are shared across thousands of users, making broad IP blocks difficult without affecting legitimate users.

What this enables attackers to do

With residential proxies, attackers can:

Hide behind legitimate IP addresses that security systems trust
Bypass geo-restrictions to attack from what appears to be a local source
Distribute attacks across thousands of residential IPs to avoid detection
Make malicious traffic look like it comes from normal users

In my work at Peakhour.IO, we've seen a rise in attacks originating from these residential proxies. The Chinese state-sponsored group Camaro Dragon showed the potential of the model when they developed custom firmware for TP-Link routers, turning them into residential proxies for their operations. This method let them bypass traditional defences like GeoIP blocking because the traffic appeared to come from normal homes.

The broader trend is commoditisation. You no longer need to be a nation-state actor to use them. Anyone with a few hundred dollars can set up a residential proxy farm or use services like iProxy.online to route their traffic through mobile networks.

How it obscures an operator's infrastructure

State-sponsored actors such as Volt Typhoon have used compromised small-office and home-office network devices to proxy command-and-control traffic. That use maps to MITRE ATT&CK's proxy technique, T1090: the relay conceals the infrastructure behind the operation.

It does not follow that every stage of an intrusion, including data collection or exfiltration, travelled through residential proxies. Keep the claim attached to the observed behaviour: compromised edge devices carried or concealed operational traffic.

For a precise explanation of the mapping, read Where Residential Proxies Fit in MITRE ATT&CK.

How it enables credential stuffing and other attacks

Credential stuffing attacks have hit Australian businesses hard, with companies like The Iconic, Guzman y Gomez, Dan Murphy's, and others falling victim. Residential proxies help these attacks work because attackers can distribute their login attempts across thousands of residential IP addresses.

When an attack comes through residential proxies, each login attempt appears to come from a different legitimate user. IP-based rate limiting fails because no single IP shows suspicious volume. Even when security teams try to block suspicious regions, proxies let attackers appear to be local customers.

According to our research at Peakhour.IO, traditional IP intelligence services are failing to detect these proxies. Tests we conducted showed that top providers like Maxmind detected 0% of residential proxies, while even the best performer, IP Quality Score, only identified 24%.

The traffic share can be significant. We've seen cases where up to 40% of traffic to Australian e-commerce sites consists of bots using residential proxies for credential stuffing, price scraping, and inventory checking. This puts customer accounts at risk, distorts analytics, and wastes marketing budgets on fake traffic.

The TCP/IP fingerprinting challenge

One aspect of mobile proxies that makes them even more effective is the ability to match TCP/IP fingerprints with the purported device. As Sabir from iProxy.online explains:

"In some cases, your fingerprint, TCP fingerprint should match to your user agent. For example, if you like pretending to be a Mac user or iOS user or Windows user, your TCP fingerprint should be matched with your browser fingerprint."

This means detection mechanisms that look for mismatches between TCP/IP fingerprints and browser types can also be bypassed.

Anybody can now set them up

The barrier to entry for setting up residential proxies has fallen sharply. Companies like Proxidize market their products as simple to use, with statements like "Start using Proxidize in less than 60 seconds."

There are YouTube videos showing how to earn "passive income" by setting up proxy farms. One video explains how hosts can earn "$200 a month minimum" by hosting Proxidize hardware in their homes.

With iProxy.online, it's even simpler—just install an app on an Android phone, and you have a mobile proxy. As Sabir explains, "Actually your expenses are like you pay like for the SIM card, you pay a small subscription fee to the service and you just... That's it. It requires like one minute of work just to download an app."

This accessibility means residential proxy use is no longer limited to nation-states and sophisticated cybercriminal organisations. It is now within reach of anyone with basic technical skills.

The solution: per-connection detection

The rise of residential proxies means IP reputation databases are not enough on their own. As I've been explaining in my talks, "Residential proxies pose a significant challenge to traditional defense mechanisms... making malicious traffic appear legitimate."

The practical answer is per-connection detection that looks at network behaviour patterns rather than just IP addresses. At Peakhour.IO, we stack detections across layers to identify and mitigate proxy traffic.

A useful technique is analysing protocol behaviour. When traffic passes through a residential proxy, there are often detectable differences between network signatures (which come from the proxy) and the application behaviour (which comes from the third-party application).

These techniques can identify proxy connections even when they come from legitimate residential IP addresses, giving defenders a way to respond without blocking whole residential or mobile networks.

A call to action for businesses

If you're a business, especially in e-commerce, financial services, or any industry that relies on user accounts, residential proxy traffic needs to be part of your security model.

Traditional security approaches based on IP reputation, geolocation, and rate limiting are no longer sufficient. You need to implement per-connection detection that can identify residential proxy usage regardless of the source IP address.

At Peakhour.IO, we've seen organisations fall victim to attacks that could have been prevented with the right detection mechanisms. Waiting until credential stuffing or data exfiltration becomes visible is the expensive way to learn this lesson.

IP addresses alone can no longer tell us who to trust. We need to look deeper at each connection to protect systems and data now that proxy networks are easy to rent or build.

How AI Agents Are Writing Custom Exploits

2025-02-17T14:00:00+11:00

The trend is clear enough: AI agents can now craft exploits by analysing security responses in real time. That puts static security rules and traditional Web Application Firewalls (WAFs) under direct pressure. Here is why.

Last week I examined an AI agent probing a test environment. It sent requests, observed the responses, then built bypasses for each security control in sequence. The agent identified pattern-based rules, learned their structure, and generated variations until it found gaps. It did this without human intervention.

This kind of automated exploit development changes the operating conditions for defenders. Traditional defences rely on known patterns: regex rules, signature matching, IP reputation. Those approaches assume threats follow recognisable templates. That assumption is becoming much weaker.

Consider a standard WAF rule blocking SQL injection through pattern matching. An AI agent examines the responses, determines the matching patterns, then generates unique variants designed to bypass those rules while maintaining the exploit's functionality. The variants evolve as the agent learns which approaches succeed.

The same pattern applies beyond SQL injection. AI agents can probe XSS filters, access controls, and input validation in the same systematic way. Each static rule becomes something the agent can test, infer, and work around.

By 2026, I estimate AI agents will drive over 50% of exploit attempts. The speed of this shift stems from three factors:

AI agents operate continuously, testing and learning 24/7
Successful exploits feed back into training data, improving future attempts
Agents share knowledge, building collective intelligence about bypass techniques

This is the practical limit of static security. Traditional WAFs that rely on fixed rules and signatures struggle to keep pace with AI-generated exploits. Each rule loses value as agents discover new bypasses.

The path forward requires a different security architecture. Organisations need context-aware systems that analyse intent, not just patterns. These systems use behavioural AI to distinguish between legitimate requests and exploit attempts, even when the request structure changes.

Key elements of this new approach include:

Intent analysis through deep inspection of request sequences
Behavioural modelling of normal vs malicious patterns
Real-time adaptation as new exploit techniques emerge
Proactive identification of potential vulnerabilities
Integration of threat intelligence across systems

The challenge intensifies when AI agents leverage residential proxies. These proxies route traffic through real consumer IP addresses, bypassing location-based blocks. An AI agent operating through residential proxies can probe defences while appearing to come from legitimate users worldwide.

This combination of AI-driven exploit generation and residential proxy networks makes traditional controls much less reliable. Organisations that continue to rely on static rules face a growing risk of compromise.

Security teams should respond now:

Audit existing WAF rules to identify pattern-based weaknesses
Deploy behavioural analysis capabilities to detect malicious intent
Implement adaptive security controls that evolve with threats
Monitor for AI-driven probing attempts
Build detection for residential proxy traffic

Teams that wait risk watching their defences get mapped and bypassed by automated agents. Static rules alone are not enough for this level of probing.

This also requires a shift in how we approach security. Rather than only blocking specific patterns, we need to understand and control the broader context of system interactions. The goal moves from "preventing known attacks" to "identifying and blocking malicious behaviour, regardless of its specific form."

Adaptive security systems need to reason about traffic in the same context-aware way as the agents probing them. Static rules still have a role, but they cannot be the centre of the defence.

Security strategy needs to account for this now, because AI-driven probing is no longer hypothetical.

The Reasoning Model Revolution

The emergence of open reasoning models like DeepSeek pushes this further. Unlike traditional AI that follows programmed patterns, reasoning models understand context and adapt strategies dynamically. That creates harder security problems.

Consider how a reasoning model approaches security testing. Rather than simply probing for weaknesses, it builds a conceptual model of the system's defences. It understands the purpose of security controls and reasons about potential bypasses. That allows it to generate novel attack strategies that were not present in training data.

DeepSeek demonstrates this shift. Within months of release, it showed capabilities matching established players at a fraction of the cost. This rapid progress comes from reasoning models' ability to understand and adapt, not just pattern match.

For security teams, that is a material challenge. Reasoning models do not just find gaps in rules. They infer why rules exist, deduce the logic behind security controls, and generate attacks that exploit underlying assumptions.

By 2027, I expect reasoning models to handle most security testing and exploit development. Their advantages prove too compelling:

They understand system architecture and security principles
They generate novel attack strategies through reasoning
They adapt in real-time based on system responses
They share and build upon successful approaches

This shift pushes traditional security approaches past their useful boundary faster than many teams expect. Pattern matching and rule-based systems cannot reliably counter an opponent that understands and reasons about their operating logic.

The combination of reasoning models with residential proxies is especially difficult to defend against. Reasoning models devise sophisticated attacks while proxies mask their origin. Each successful breach feeds back into the model's understanding, improving future attempts.

Security teams must embrace a new paradigm focused on:

Understanding attack narratives rather than patterns
Detecting anomalous reasoning rather than known signatures
Building systems that adapt to novel attack strategies
Implementing security that reasons about intent
Developing defences that evolve through adversarial learning

Security systems need to reason about threats as effectively as the AI agents probing them. Traditional approaches will fail against opponents that understand the logic behind security controls and devise creative bypasses.

The age of reasoning security has begun. Static rules and pattern matching are no longer enough on their own.

The question is how quickly security teams can move from fixed patterns to adaptive, intent-aware defence.

A/B Testing, Bots, and the New Normal

2025-02-13T14:00:00+11:00

Marketing traffic is no longer just human traffic. We spent months analysing how AI agents interact with websites, and the findings put pressure on a core assumption behind digital marketing: that campaign data mostly reflects human behaviour.

Consider a simple A/B test on a landing page. The data shows a clear winner, with conversion rates 30% higher than the control. You ship the change, then the live result misses the forecast. One possible cause is that AI agents were counted in the test population.

This is not speculation. We have observed AI agents, from shopping bots to research tools, interacting with marketing campaigns in ways that weaken traditional metrics. These agents do not behave like people. They optimise for efficiency, not experience. They follow patterns, not preferences.

The consequence is straightforward. A/B test results may reflect what works best for AI agents rather than human users. Conversion metrics may combine human decisions with automated actions. A marketing funnel can end up optimising for the wrong audience.

The scale became clear when we analysed traffic patterns across various sectors. In ecommerce, AI agents now account for up to 40% of product page views. For content sites, the figure rises to 60% for certain categories. These are not simple scraper bots. They interact with content, follow links, and even complete transactions.

Blocking all of this traffic is not a practical answer. Many agents serve legitimate purposes, from price comparison to content aggregation. Marketing teams now need to recognise and measure a dual audience: human and AI.

Through our research, we have identified three shifts in marketing strategy:

First, marketing funnels need to bifurcate. One path should be optimised for human users, with emphasis on engagement and experience. Another should serve AI agents, with structured data and efficient access to information.

Second, A/B testing needs new frameworks. Analysis should separate AI and human interactions. That requires stronger detection methods and separate datasets for each audience type.

Third, attribution models need to evolve. When an AI agent researches products before recommending them to a human user, who gets credit for the conversion? The traditional last-click model does not capture that sequence well.

The problem is not limited to metrics. AI agents use residential proxies to mask their nature, making detection difficult. They learn and adapt, which means identification methods need regular updates. They also operate at scale, potentially overwhelming analytics systems.

There are useful opportunities here, but they need to be treated with discipline. Organisations that adapt their marketing strategies can optimise content delivery for both audiences. They can use AI agents as a marketing channel where that makes sense. They can also build campaigns that are less exposed to polluted measurement.

The path forward starts with a clearer operating model. Marketing teams need to treat AI agents as a distinct audience segment, with different behaviours and requirements. They also need tools and metrics that measure performance across both audiences without mixing them together.

Our research suggests several practical steps:

Implement robust bot detection systems to identify AI agent traffic. This gives teams the basis for separate analysis of human and AI interactions.

Develop structured data formats that serve AI agents efficiently while maintaining rich experiences for human users.
Create attribution models that account for the role of AI agents in the customer journey.
Monitor residential proxy usage to understand the true nature of website traffic.
Build marketing strategies that balance the needs of both audience segments.

Marketing data will keep changing as AI agents become more sophisticated. The line between human and automated interactions may blur further. Teams that recognise the split can make better decisions about testing, attribution, and campaign design.

Organisations that continue to treat all traffic as human risk optimising for the wrong audience. Organisations that separate the signal can make better use of both human and AI traffic.

Our next challenge is understanding how AI agents influence human decision-making. That is a separate question.

The views expressed in this article reflect our research and analysis of AI agent behaviour in marketing environments. We encourage organisations to conduct their own analysis and develop strategies suited to their specific circumstances.

When Bots Are Your Primary Users

2025-02-12T14:00:00+11:00

APIs have mostly been designed for human developers first. Reasoning models like DeepSeek make that assumption weaker. If an agent can inspect an API, plan a sequence of calls, and adapt as it goes, it becomes a different kind of consumer.

That is the part worth paying attention to. Many APIs still assume a human-first model while AI agents become regular, and in some cases primary, users. These are not simple scraping bots or automation scripts. Modern AI agents can plan, reason, and change their behaviour. They interact with APIs in ways many teams did not account for when they wrote their OpenAPI specifications and documentation.

A human developer reads documentation, tries a few calls, and works through errors. An AI agent can process the whole API surface in seconds, generate thousands of possible interaction patterns, and test them systematically. That difference changes both API design and API security.

The issue is not limited to technical specifications. API logs already show traffic patterns that challenge older assumptions. AI agents do not follow typical "business hours" usage. They do not slow down because a workflow becomes cognitively heavy. They process responses at machine speed and chain API calls in ways human developers rarely attempt.

This shift forces us to rethink several core aspects of API design:

Structure and Format

Human-readable formats still matter, but they are not the only target. JSON and REST endpoints work well for developers who need to read and understand responses. For AI agents, there may be room for more efficient formats that optimise for machine processing rather than human comprehension.

Rate Limiting and Quotas

Most rate limiting models still assume human consumption patterns. AI agents operate at machine speed and scale. New models need to account for that processing capacity while still preventing abuse. That may mean moving from simple request counts to complexity-based quotas.

Authentication and Security

Traditional API keys and OAuth flows centre on human developers. AI agents need security models that account for how they operate. The hard problem is verifying the identity and intentions of an AI agent without weakening the security controls around the API.

Documentation and Discovery

API documentation still focuses on human understanding. For AI agents, machine-readable specifications need to go beyond OpenAPI. They should describe what endpoints do, not just how to call them.

This also changes how we monitor and maintain APIs. Traditional metrics like response time and error rates remain useful, but they do not explain AI agent behaviour on their own. How do we measure the "success" of an API when its primary users are machines that can adapt to problems and work around them?

Performance optimisation changes as well. A human developer might tolerate occasional latency. An AI agent can make thousands of calls per second, which puts more pressure on caching, edge computing, and response optimisation.

APIs are likely to split into two parallel tracks: human-oriented interfaces that prioritise developer experience, and machine-oriented interfaces optimised for AI consumption. This is not a choice between one audience and the other. It is recognition that they have different needs.

The challenge extends to business models. How do we price APIs when consumers are AI agents that can process information at machine scale? Traditional per-request pricing may not make sense when an AI can make millions of optimised calls that would take a human developer years to replicate.

Residential proxies add another layer of complexity. They allow AI agents to appear as regular users, making it harder to distinguish between human and machine traffic. That pushes API access control beyond IP-based rate limiting.

The ethical questions also matter. As APIs become primarily consumed by AI agents, teams need frameworks for responsible use. That includes asking how an API might be used inside AI systems, and what guardrails should sit around that access.

This is not about replacing human developers. It is about recognising AI agents as a new class of API consumer, with their own needs and capabilities. API design, security, and management all need to account for that.

The APIs we build today will sit under tomorrow's AI-driven systems. They need to be designed for both human and AI consumers, with clear decisions about discovery, access, rate limits, authentication, monitoring, and abuse controls.

The shift to AI-first API design is already under way. The practical question is how quickly API practices can catch up.

Our APIs have to evolve with their users.

Data-Driven Risk Management

2025-02-07T00:00:00+11:00

After our examination of Visa's Security Roadmap, this article looks at how Peakhour's contextual security approach supports Visa's third key focus area: shifting to a data-driven, risk-based approach.

The Evolution of Risk Management

Traditional security controls often rely on static rules and fixed thresholds. Visa's Security Roadmap 2025-2028 emphasises the need for dynamic, data-driven risk management that adapts to emerging threats while keeping operations efficient. That shift is important for attacks like credential stuffing and enumeration attacks, which exploit weak points in static defences.

Understanding Contextual Security

Contextual security moves beyond fixed rules by using real-time data analysis to assess risk and choose a proportionate response. It starts by collecting a broad set of signals for each interaction, including user behaviour patterns, device characteristics, network indicators like TLS fingerprints, geographic patterns, and historical trends.

Those signals feed a dynamic risk assessment engine with continuous monitoring and adaptive thresholds. Using techniques such as behavioural analysis and anomaly detection, the system can identify subtle deviations from normal activity that may signal a threat. The result is a response matched to the risk: triggering risk-based authentication, applying adaptive security measures, or initiating an automated threat response with customised rules.

How Peakhour Aligns with Visa's Vision

Our Contextual Security platform supports Visa's data-driven approach by combining multiple layers of defence. At the core is edge intelligence, which uses a global network to process data in real time, close to the user. This supports rapid identification of emerging threats, sharing threat intelligence across the network, and responding to attacks as they happen.

This is backed by advanced analytics that use machine learning models, behavioural analysis, pattern recognition, and anomaly detection. These tools are essential for identifying sophisticated threats, such as bots using residential proxies or anti-detect browsers. By analysing connection-level data, we can distinguish malicious automation from legitimate user traffic, a task traditional IP-based methods often fail.

This analysis supports risk-based decision-making. Instead of applying one-size-fits-all rules, our platform implements dynamic security measures. This includes adaptive authentication, contextual access controls, risk-based policies, and automated responses like advanced rate limiting, which can help stop distributed attacks.

Key Benefits of a Data-Driven Approach

Adopting a data-driven, contextual security model gives organisations practical advantages. It improves security through earlier threat detection and a reduction in false positives. The broader coverage protects against a wider range of attacks, from automated bots to manual fraud attempts.

At the same time, it can improve the user experience. By assessing risk more accurately, the system can reduce friction for legitimate users, support faster transactions, and make authentication less intrusive. This personalised security approach strengthens trust without sacrificing usability, a necessary balance for modern businesses.

Finally, this strategy improves operational efficiency. Automated responses reduce the need for manual review and intervention, optimising resource allocation. The scalable nature of the platform ensures that security can keep pace with business growth, providing a more sustainable way to manage risk.

Implementing Contextual Security

Organisations can implement contextual security by assessing their current state: reviewing existing controls, identifying data sources, and evaluating current capabilities. A planning phase then defines objectives, selects appropriate solutions, and establishes key performance metrics. Deployment follows, with systems installed, rules configured, staff trained, and performance monitored continuously.

To maximise effectiveness, teams need high-quality, real-time data collection while maintaining user privacy. They also need a robust analysis framework: well-defined risk models, adaptive thresholds, and clear policies for automation. Finally, response mechanisms should be practical to operate, with automated workflows and controls that can be monitored and refined over time.

Real-World Applications and Future Considerations

In practice, contextual security applies across several security workflows. For authentication, it enables risk-based multi-factor authentication and adaptive policies. In transaction monitoring, it allows for real-time analysis and fraud prevention. For access control, it supports dynamic permissions based on context-aware rules.

Looking ahead, organisations should prepare for the increasing role of advanced analytics, including AI and predictive analytics. Integration with other systems through APIs will be important, as will adapting to evolving regulatory requirements and new threat vectors.

Final Thoughts

The shift to data-driven risk management is an important change in security strategy. Peakhour's contextual security solutions help organisations align with Visa's vision while improving security, efficiency, and user experience. Moving beyond static rules to an adaptive defence gives businesses a better way to protect themselves and their customers in a more complex digital environment.

Learn how Peakhour's contextual security solutions can help your organisation implement data-driven risk management aligned with Visa's Security Roadmap 2025-2028. Contact our team to improve your security posture.

Why Reasoning Models Like DeepSeek Change Everything

2025-02-03T08:13:00+11:00

Open reasoning models change how we need to think about automation and security. Looking at models like DeepSeek, the important shift is not another small gain in AI capability. It is the move towards autonomous agents that can plan, reason, and adapt without human guidance.

This became clear while analysing recent credential stuffing attacks. The patterns showed attackers using AI agents to probe systems, identify vulnerabilities, and craft custom exploits. These were not pre-programmed scripts following rigid rules. They were agents making decisions based on the system's responses.

The implications go beyond security. Consider how marketing teams usually approach A/B testing and campaign optimisation. Most tools and frameworks assume automation follows fixed paths: if this happens, do that. Reasoning models do not fit that model. They can work without predefined decision trees or explicit step-by-step instructions. They observe, learn, and create their own strategies.

This forces us to rethink basic assumptions about digital interactions. When an API call could come from an AI agent rather than a script, how do we distinguish friend from foe? Traditional markers such as request patterns, user agents, and IP addresses carry less weight when an agent can analyse and adapt to detection methods.

The same problem applies to customer engagement. Marketing funnels designed for human decision-making now face AI agents that can evaluate options systematically, compare alternatives across multiple sources, and make optimised choices. The customer journey stops being a neat linear path and becomes a space where AI agents operate alongside human users.

Reasoning models also challenge the way we approach bot management. Traditional methods focus on identifying automated behaviour: patterns that deviate from human norms. But what happens when AI agents can mimic human behaviour while operating at machine speed? The line between human and automated traffic becomes harder to draw.

Through conversations with security teams, I have seen this pattern emerge. They report sophisticated attacks that adapt in real-time, probing defences and adjusting tactics based on system responses. These are not pre-programmed behaviours. They are reasoning models understanding and responding to defensive measures.

The business impact extends beyond security. Companies need to adapt digital infrastructure for a world where AI agents become primary users. That means rethinking API design, service architecture, and customer interaction models. The question is not whether to support AI agents, but how to do it safely and effectively.

Authentication is a good example. Traditional systems often rely on proving human presence through CAPTCHAs, behaviour analysis, and device fingerprinting. In a world of reasoning models, we need approaches that focus on intent and trust rather than a simple human versus machine test.

The path forward is a shift in perspective. Rather than only trying to block or restrict AI agents, we need systems that can interact with them safely. That means moving from static rule-based security to contextual analysis that understands and adapts to agent behaviour.

The strategic implications for businesses are significant. Success in this environment requires a clear understanding of how reasoning models operate. Companies must redesign digital interfaces to support both human and AI interactions while maintaining security and control.

From my analysis of current trends, this change is accelerating. Each advance in reasoning models expands their capability and autonomy. Organisations that adapt their strategies now will be better positioned as this digital environment changes.

The rise of reasoning models is more than another technology upgrade. It changes how we approach automation, security, and digital interaction. Organisations need systems capable of engaging safely and effectively with autonomous AI agents.

The question is not whether reasoning models will change business operations. They already are. The practical question is how quickly organisations can adapt their strategies and infrastructure, and whether they can do it without losing control of trust, security, and user experience.

Did Residential Proxies enable a $600 Billion loss?

2025-01-31T00:00:00+11:00

The DeepSeek story puts residential proxy networks under scrutiny as a possible factor in AI's latest market disruption. In January 2025, the Chinese startup's emergence erased $600 billion from Nvidia's market value by demonstrating AI capabilities that match industry leaders at a fraction of the cost.

The path to this capability raises a practical security question for AI platforms. Leading platforms protect their APIs with multiple security layers - rate limiting to prevent mass data extraction, bot detection to block automated requests, and geoblocking to restrict access from certain regions. These measures are meant to prevent the systematic collection of training data.

Residential proxy networks create a route around those protections. These networks route traffic through household IP addresses, so requests appear to originate from homes in permitted regions. A request from a restricted location could look like legitimate traffic from Sydney, Melbourne, or Perth.

The circumstances suggest this approach is plausible. By distributing requests across millions of residential IPs worldwide, each IP could maintain human-like patterns while staying below rate limits. The aggregate data could form a substantial training set without triggering security alerts.

Meta's lawsuit against Bright Data strengthens this possibility. The case exposed how proxy providers monetise residential IPs, often without homeowners' knowledge. That model creates a global network capable of bypassing traditional security measures - exactly the type of infrastructure needed for large-scale data collection.

The residential proxy industry threatens $600 billion in business value through data theft and security bypasses. DeepSeek's impact on Nvidia's market capitalisation highlights the real-world impact of residential proxies.

For AI platforms, the question is operational. How can platforms distinguish between legitimate users and well-crafted requests through residential proxies? When geographical restrictions lose meaning, what security measures remain effective? Traditional IP Intelligence based proxy detection based on historical usage is no longer effective; per-connection proxy detection is essential.

DeepSeek's emergence suggests AI security teams need to revisit their assumptions. The potential use of residential proxy networks to dissolve digital borders challenges current approaches to platform protection.

Preventing Enumeration Attacks

2025-01-24T00:00:00+11:00

After our overview of Visa's Security Roadmap 2025-2028, this article looks at the first focus area: preventing enumeration attacks. Visa reports a 40% increase in enumeration attacks in the first six months of 2023 compared with the previous period, and more than US$1.1 billion in global fraud losses from these attacks over the year to 30 September 2023.

Visa defines enumeration and account testing as criminal practices where fraudsters use automation to test and guess payment credentials, which can then be used for fraudulent transactions. In card-testing campaigns, attackers send large numbers of low-value authorisation attempts to validate a primary account number, expiry date, or CVV2. They tend to target online merchants with weaker fraud controls because the merchant site becomes the testing ground while issuers, acquirers, and cardholders absorb the downstream damage.

The volume share can look small. Visa notes that these attacks contribute to less than 1% of global card-not-present volume. That can make the risk easy to underweight until the business sees the operating cost: processor scrutiny, chargeback pressure, support load, infrastructure spikes, blocked genuine customers, and fraud teams trying to reconstruct what happened after the card data has already been validated somewhere else.

The Risk Is Operational Before It Is Regulatory

Enumeration is not only a payment fraud pattern. It is a production traffic problem. The attack arrives as normal-looking checkout or payment API requests, often distributed across many IPs, accounts, devices, cards, and merchants. If the only defence is a fixed IP threshold, the attacker can slow down, rotate infrastructure, or push attempts through residential proxy networks that look closer to consumer traffic.

That is why Visa's roadmap points to authentication controls, anomaly detection, real-time monitoring, velocity thresholds, CVV2 for unsecure transactions, and retries with different values as indicators of account testing behaviour. The common thread is evidence. Teams need to see the pattern across attempts, not just one failed authorisation at a time.

For merchants and acquirers, the first decision is scope. Which routes can submit payment credentials? Which APIs can create checkout sessions, payment intents, or tokenisation requests? Which responses tell an attacker whether the credential is likely valid? Which logs show retries with changed values? Which controls can act before the traffic reaches the processor?

VAMP Raises the Need for Cleaner Evidence

Visa's updated Visa Acquirer Monitoring Program (VAMP) is effective 1 April 2025. In the roadmap, Visa says VAMP brings more aligned fraud thresholds for domestic and cross-border card-not-present transactions and incorporates new enumeration criteria based on the number of enumerated authorisation transactions and the enumeration rate identified by the VAAI Score.

That does not mean every merchant needs the same control design. It does mean acquirers and merchants need better visibility into whether a burst of payment activity is genuine demand, a broken integration, friendly fraud, or enumeration. When traffic is distributed, the evidence needs to include more than source IP. Useful signals include route, account state, card-attempt cadence, response codes, device or browser consistency, proxy likelihood, country and ASN changes, header and TLS patterns, and whether retries are changing only the values an attacker is trying to validate.

Peakhour's role is at the web and API edge. Bot Management, Advanced Rate Limiting, Residential Proxy Detection, WAF, and log forwarding can help teams detect automated payment attempts, slow or block abusive routes, identify proxy-backed traffic, and retain decision evidence. Those controls support a payment security program; they do not determine VAMP standing, replace acquirer guidance, or provide legal advice.

Rate Limits Need to Follow the Attack Shape

Simple rate limits still help, but card testing rarely follows one neat source. A useful rate limit strategy looks at multiple keys: route, payment action, account, session, token, card fingerprint where appropriate, device signal, IP, ASN, country, response result, and time window. The limits should also distinguish between customer actions. A checkout page, card add route, refund path, gift card purchase, and payment authorisation API should not all share one generic threshold.

Teams also need to decide what the control does. Some traffic should be blocked. Some should be slowed. Some should be challenged before payment. Some should be logged and reviewed because false positives would create more harm than the risk being reduced. The right action depends on business context, fraud exposure, customer value, and the confidence of the signals.

Residential proxy abuse is a good example. A residential IP does not prove fraud. Many genuine users sit behind shared or mobile networks. But residential proxy use combined with high-cardinality card attempts, changed CVV2 values, first-seen devices, failed authorisations, and unusual checkout cadence is a stronger signal. The value is correlation, not a single magic indicator.

A Practical Review Path

Teams preparing for enumeration risk should start with the payment routes rather than with a vendor checklist.

Map every route that can create, submit, modify, or retry a payment attempt.
Review response messages and status codes for accidental validation clues.
Check whether logs can show velocity, retries with changed values, and route-level concentration without storing sensitive card data.
Apply route-aware rate limits and bot controls before processor calls where possible.
Add proxy, device, session, and behaviour signals to separate normal checkout friction from testing behaviour.
Keep evidence of policy version, action, route, and signal set so fraud and compliance teams can review outcomes.

The caution is important: do not turn payment logging into a second store of cardholder data. Enumeration defence needs enough evidence to detect and investigate abuse, but PCI DSS and privacy expectations still require careful handling of cardholder data, tokens, logs, and support exports.

What This Means for Peakhour Customers

Enumeration prevention is not a single feature. It is a control path around payment routes: classify the request, evaluate the signals, act proportionately, and keep evidence. Peakhour can help by applying those decisions at the edge before abusive traffic reaches the origin or payment integration.

The business value is not only fewer bad requests. It is cleaner payment telemetry, faster fraud review, fewer avoidable processor calls, and a better basis for conversations with acquirers when suspicious activity appears. Visa's roadmap makes that direction clear: payment security is moving toward data-driven, evidence-backed controls that can recognise automation abuse without blocking genuine customers by default.

Visa's Security Roadmap 2025-2028

2025-01-21T00:00:00+11:00

Visa's Security Roadmap 2025-2028 for Australia is not just a payments strategy document. It is a signal about where fraud, application security, authentication, and compliance work are converging for merchants, acquirers, issuers, gateways, and service providers.

The timing matters. Visa's roadmap cites Australian card fraud rising 32% to A$762 million in 2023, with unauthorised card-not-present fraud increasing 33% to A$688 million. Scam losses reached A$2.7 billion in 2023, and reported data breaches increased 19% in the second half of 2023 compared with the first half. The pressure is not coming from one direction. Payment teams are dealing with automation abuse, social engineering, compromised credentials, weak merchant onboarding, third-party exposure, and new payment experiences at the same time.

Visa groups its roadmap into six focus areas: preventing enumeration attacks, continued investment in secure technologies, data-driven risk, resilience against fraud and scams in the era of AI, stronger cyber security posture, and secure digital payment experiences. For Australian businesses, the more useful way to read it is as a set of operational themes.

Automation Abuse Has Become a Payment Control Issue

Enumeration attacks sit first in the roadmap for a reason. Visa defines enumeration and account testing as automation used to test and guess payment credentials that can later be used in fraudulent transactions. The attacks often appear as high-speed card testing against online merchants, with low-value attempts used to validate PAN, expiry, or CVV2 combinations.

Visa reports a 40% increase in enumeration attacks in the first six months of 2023 compared with the previous period, and more than US$1.1 billion in global fraud losses from enumeration attacks over the year to 30 September 2023. The updated Visa Acquirer Monitoring Program (VAMP), effective 1 April 2025, adds enumeration criteria alongside broader fraud and dispute monitoring.

The implication is practical: merchants and acquirers need route-level evidence, anomaly monitoring, velocity controls, and a way to identify distributed automation before it becomes payment fraud. IP-only controls are weak when attacks use residential proxies, first-seen devices, and slow distributed attempts. Peakhour's bot management, residential proxy detection, advanced rate limiting, and edge logging can help support that evidence path, but the business still needs payment-flow ownership and acquirer alignment.

Authentication and Tokenisation Are Moving Together

Visa's secure technology theme is not simply "add more authentication." The roadmap ties tokenisation, EMV 3DS, biometric or in-app authentication, passkeys, and Click to Pay into the same customer and fraud problem: protect credentials while reducing unnecessary friction.

Tokenisation reduces the value of exposed card data by replacing a card number with a token. Visa notes that the Visa Token Service has passed one billion tokens in Asia Pacific and that merchants adopting VTS for digital payments saw payment fraud rates reduced by more than half in the cited Asia Pacific analysis. But the roadmap also flags token provisioning fraud, where bad actors illegitimately provision tokens and then monetise them quickly.

That is why authentication quality matters. Visa says issuers are being mandated to move away from SMS OTP as the sole authentication factor by 2026, toward methods such as biometric, in-app, app-to-app, or passkey-based authentication. For merchants, updated Visa Secure minimum data requirements push more complete authentication data into the decision process.

For application teams, the lesson is that checkout security is not a single login prompt. It includes account creation, saved-card use, card add, token provisioning, checkout, refund, and support paths. A risk-based challenge should appear where the action justifies it, not everywhere by default.

Risk Decisions Need Better Data, Not Just More Data

The roadmap's data-driven risk theme is about using available payment and authentication data to reduce fraud and false positives. Visa points to EMV 3DS data elements, Visa Secure requirements, risk-based authentication, and issuer decisioning as examples of how better data quality can change outcomes.

More data is not automatically better. It has to be accurate, relevant, protected, and available at the moment of decision. A fraud team may need account history, device consistency, proxy likelihood, card-attempt cadence, transaction context, and previous response outcomes. A compliance team may need to know why that data is collected, where it is retained, and who can query it.

This is where contextual security becomes useful. Peakhour's Contextual Security approach combines request, route, account, network, device, and behaviour signals so teams can allow, challenge, rate limit, block, or log based on risk. The control is strongest when the decision record stays attached to the event: signal set, policy version, action, and outcome.

AI Raises Scam and Fraud Pressure, But It Is Also Part of Detection

Visa frames AI in both directions. Generative AI lowers the barrier for phishing, social engineering, deepfakes, and personalised scam content. At the same time, Visa points to its long history using AI and machine learning in payment fraud detection, including around 150 AI and machine learning models in production.

For businesses outside the payment network, the message is not "buy AI." It is to prepare for more scalable deception and faster abuse cycles. Fraud controls need to watch for account creation abuse, credential stuffing, payment testing, suspicious onboarding, transaction anomalies, and customer manipulation signals. Human review still matters because authorised scams can look different from unauthorised account compromise.

Peakhour's role is strongest around the request and account edge: identifying automation, proxy-backed traffic, route abuse, credential risk, and abnormal behaviour before fraud reaches sensitive application paths. Those signals can feed fraud review and incident response, but they should be used with privacy, false-positive, and customer-impact controls.

Cyber Posture Is Now Part of Payment Ecosystem Resilience

Visa's fifth theme connects payment fraud to cyber security posture. PCI DSS remains mandatory for entities storing, processing, or transmitting Visa cardholder data. Visa also highlights third-party agent (TPA) registration, its Account Information Security program, third-party service provider risk, breach trends, and preparation for broader AES support by 2030.

For Australian businesses, this is a reminder that payment risk is not limited to the payment processor. A breach of a CMS account, a third-party script, a weak checkout plugin, a vulnerable API, a compromised support tool, or an unmanaged service provider can affect the payment environment. PCI scope and third-party oversight need to include the systems that can change or observe checkout, not only systems that store card numbers.

Peakhour can help with application-layer controls around WAF, API protection, bot management, rate limiting, DDoS mitigation, and log forwarding. Those controls can support evidence for payment security and cyber posture. They do not replace PCI DSS validation, TPA obligations, acquirer requirements, or legal review.

New Payment Experiences Need Security Built Into the Flow

Visa's final theme covers digital payment experiences such as Click to Pay, passkeys, Flex Credential, and Tap to Everything. These changes are about reducing manual card entry, password dependence, and fragmented checkout experiences while preserving cardholder verification and transaction security.

The security work for merchants is to keep pace with those flows. New payment methods bring new integration paths, data elements, redirects, APIs, support workflows, and customer education needs. The right question is not only "does the new payment method work?" It is "which systems can affect it, what data is passed, how is the customer verified, what fraud signals are available, and what evidence remains after a dispute or incident?"

What Businesses Should Do Next

Read the roadmap as an operating agenda. Map payment and account routes. Identify where automation can test credentials or cards. Review SMS OTP dependence. Check whether tokenisation and 3DS data are being used well. Validate which vendors affect checkout and payment security. Confirm that logs can support fraud review without capturing sensitive card data. Tune rate limits and bot controls by route, not only by IP.

The next few years of payment security will reward teams that can make proportionate, evidence-backed decisions. That is the thread running through Visa's roadmap and through Peakhour's edge security work: see the request in context, choose the right action, and keep enough evidence for fraud, security, and compliance teams to explain what happened.

How Bots Are Corrupting Your A/B Testing Data

2025-01-20T00:00:00+11:00

Bot traffic contaminates A/B testing results and can undermine marketing strategy. Your testing programme is exposed when residential proxy networks generate fake interactions (e.g. click fraud) that appear to come from your target market.

These residential proxies hide behind real household internet connections in the targeted geographic areas. When a bot network routes traffic through Sydney IP addresses to masquerade as real Australians, your analytics counts that traffic as legitimate local engagement. Because the traffic matches your demographic and geographic targeting profile, traditional detection methods become less effective.

This contamination affects the accuracy of the marketing strategy. Your A/B tests should show clear winners, but the results are masked by bot behaviour rather than real user preferences. Marketing teams then optimise campaigns from false signals, wasting budget and time on the wrong opportunities. The data starts driving decisions that harm conversion rates and revenue.

The scale of the problem continues to grow. Residential proxy services now offer millions of local IPs in every market. They rotate these IPs automatically and match real browser characteristics. Without specialised detection such as Peakhour A/B Testing Protection, this traffic can appear identical to genuine users in your analytics.

Each day without detection compounds the damage. Tests generate misleading data that guides strategic decisions. Marketing teams spend hours analysing invalid results and implementing changes that reduce performance. Budget allocated to testing delivers diluted ROI as optimisations based on bot data decrease conversion rates.

Traditional bot protection fails against this distributed threat. IP-based detection cannot identify residential proxy traffic that matches your target geography. Rate limiting proves ineffective against attacks spread across thousands of residential IPs. These bots evade basic JavaScript challenges through sophisticated browser emulation.

Peakhour's A/B Testing Protection uses network fingerprinting to detect residential proxy traffic. Our system analyses subtle patterns in how these proxies connect and behave, identifying bot networks that other solutions miss. We maintain a real-time database of residential proxy services to block new threats as they emerge.

Our customers have discovered that 40% of their test traffic came from bots. After implementing protection, they achieved:

Valid test results reflecting real user preferences
Increased conversion rates from accurate optimisation
Reduced waste of marketing team time and resources
Protection of testing budget from invalid traffic
Confidence in strategic decisions based on clean data

The rise of residential proxies has amplified bot threats to A/B testing. Traffic that appears to come from local users may mask sophisticated bot networks. Protecting your testing programme requires detection that goes beyond IP addresses and basic challenges. Contact us to learn how Peakhour can help secure your A/B testing data and keep optimisation decisions grounded in real users.

How MTU Fingerprinting Identifies VPNs and Mobile Users

2025-01-15T14:00:00+11:00

For traffic analysis, it helps to know how a user reached the service. Are they on a home network, a mobile connection, or a VPN? Deep packet inspection is invasive, but TCP handshake metadata can still carry useful context about the Maximum Transmission Unit (MTU) a connection appears to be using. By analysing those inferred MTU values, we can build "fingerprints" that point to the underlying network technology carrying the connection.

This article looks at how common technologies affect MTU values and shows how a SQL query can turn that data into useful network labels.

What is MTU and Why Does it Change?

The Maximum Transmission Unit (MTU) is the largest data packet, or frame, that a network-connected device can transmit. On standard Ethernet networks, this value is typically 1500 bytes. Larger payloads have to be split into chunks that fit that limit.

Encapsulation and Tunneling

The value starts to shift when tunnelling protocols are involved, including those used by VPNs and mobile networks. These protocols wrap the original data packet inside another packet, a process called encapsulation. The outer packet has its own headers for routing and management.

This encapsulation "steals" space from the original 1500 bytes available on the physical network. If a tunnelling protocol adds 60 bytes of headers, for example, the maximum size for the original data packet is now 1440 bytes (1500 - 60).

The Problem with Fragmentation

What happens if a device tries to send a 1500-byte packet through this 1440-byte tunnel? The packet has to be broken into smaller pieces, a process called fragmentation. It works, but it is inefficient. Fragmentation consumes CPU resources on the router performing it, adds header overhead to each fragment, and requires the receiving device to reassemble the pieces. The result is lower speed and higher latency.

To avoid that penalty, operating systems and network devices reduce the MTU of the connection to account for the tunnel's overhead. The amount of the reduction follows from the tunnelling protocol in use. That predictable drop is the basis for MTU fingerprinting.

A Guide to Common MTU Values

Different technologies add different overheads, which produces distinct MTU values.

WireGuard

WireGuard is a modern VPN known for its efficiency, but it still adds overhead.

IPv4 Overhead: 60 bytes (20-byte IPv4 header + 8-byte UDP header + 32-byte WireGuard header).
IPv6 Overhead: 80 bytes (40-byte IPv6 header + 8-byte UDP header + 32-byte WireGuard header).

On a standard 1500-byte network, that produces predictable MTU values:

1500 - 60 = 1440 bytes (WireGuard over IPv4)
1500 - 80 = 1420 bytes (WireGuard over IPv6)

There is a special case with ISPs that use DS-Lite (Dual-Stack Lite) to carry IPv4 traffic over an IPv6 network. This adds another 40-byte IPv6 header, reducing the MTU further.

1420 - 40 = 1380 bytes (WireGuard over DS-Lite)

OpenVPN

OpenVPN is another common VPN solution, but its fingerprint is less tidy. Instead of setting a static interface MTU, OpenVPN often uses a feature called mssfix. This dynamically adjusts the Maximum Segment Size (MSS) value within the TCP headers of encapsulated packets to prevent fragmentation.

The MSS is the MTU minus the IP and TCP header sizes (typically 40 bytes for IPv4). The exact MSS value, and therefore the effective MTU, depends on OpenVPN's configuration, including the transport protocol (UDP or TCP), cipher, MAC algorithm, and compression. As noted by security researcher ValdikSS, these unique MSS values can be used to fingerprint a connection with high precision. For example, a common configuration might result in an MSS of 1369, which corresponds to an effective MTU of 1409 (1369 + 40).

For general analysis, connections with an MTU around 1400 or 1380 bytes often indicate OpenVPN or other VPN usage, especially when seen with other factors.

Mobile Networks (LTE & 5G)

Mobile networks also modify MTU values. When your phone connects to the internet, its data is tunnelled through the carrier's network using the GPRS Tunnelling Protocol (GTP). This encapsulation adds its own layer of headers.

As detailed by Nick vs Networking, the typical overhead for GTP traffic over an Ethernet transport network is 50 bytes:

14 bytes for the Ethernet header
20 bytes for the outer IPv4 header
8 bytes for the UDP header
8 bytes for the GTP header

For a mobile carrier using a standard 1500-byte MTU on its transport network, the maximum MTU available to the user's device is 1450 bytes (1500 - 50).

Mobile devices don't guess this value; they are explicitly told what MTU to use by the network during the connection setup process (via Protocol Configuration Options). Mobile operators have two choices to avoid fragmentation:

Increase Transport MTU: Enable jumbo frames (for example, 1600 bytes or more) on their internal network to accommodate the 50-byte overhead and still provide a full 1500-byte MTU to the user.
Lower Advertised MTU: Advertise a lower MTU to the user's device. This is why values such as 1450 are common. Some operators may configure a more conservative MTU, such as 1300 bytes, to maintain stability across all parts of their network.

Other Common Values

Standard Ethernet: The baseline is 1500 bytes.
PPPoE: Common for DSL connections, adds 8 bytes of overhead, resulting in an MTU of 1492 bytes.
IPv6 Minimum: The IPv6 specification mandates a minimum MTU of 1280 bytes, so this value is also a significant marker.

Analysis with SQL

With this context, we can analyse network logs to classify user connections. The following SQL query buckets and attributes MTU values from a large dataset, turning raw numbers into meaningful labels.

The query works in several stages:

Extract Data: It parses the MTU from a fingerprint string in the logs.
Bucket MTUs: It uses a CASE statement to group MTUs. Specific known values, such as 1500, 1440, 1420, and 1380, go into their own buckets. Jumbo frames (>1500) are grouped into 100-byte buckets, and everything else is grouped into 20-byte buckets.
Attribute Buckets: In the final SELECT, another CASE statement translates those numeric buckets into human-readable descriptions based on the fingerprints we've identified.

The Query

-- Bucketing logic and attribution informed by research from:
-- https://ripx80.de/posts/06-wg-mtu/ (WireGuard)
-- https://medium.com/@ValdikSS/detecting-vpn-and-its-configuration-and-proxy-users-on-the-server-side-1bcc59742413 (OpenVPN)
-- https://nickvsnetworking.com/mtu-in-lte-5g-transmission-networks-part-1/ (Mobile Networks)
WITH base_data AS (
    SELECT
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[1])[4]) AS mtu,
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[1])[5]) AS wsize,
        toInt32OrNull(splitByChar(':', splitByChar(',', synner_fingerprint)[2])[1]) AS scale,
        (tls.handshake_rtt_us - tcp.min_rtt_us) >= 65000 AS is_high_latency
    FROM logs.client_logs
    WHERE time >= '2025-07-01' AND shielded = 0
),
main_aggs AS (
    SELECT
        CASE
            WHEN mtu = 1500 THEN 1500
            WHEN mtu = 1440 THEN 1440
            WHEN mtu = 1420 THEN 1420
            WHEN mtu = 1380 THEN 1380
            WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
            ELSE intDiv(mtu, 20) * 20
        END AS mtu_bucket,
        countIf(is_high_latency) AS high_latency_count,
        countIf(not is_high_latency) AS normal_latency_count,
        round(avg(wsize * pow(2, scale))) AS avg_real_wsize
    FROM base_data
    WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
    GROUP BY mtu_bucket
),
top_wsizes AS (
    SELECT
        mtu_bucket,
        groupArray((wsize, cnt)) AS top_wsizes
    FROM
    (
        SELECT
            CASE
                WHEN mtu = 1500 THEN 1500
                WHEN mtu = 1440 THEN 1440
                WHEN mtu = 1420 THEN 1420
                WHEN mtu = 1380 THEN 1380
                WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
                ELSE intDiv(mtu, 20) * 20
            END AS mtu_bucket,
            wsize,
            count() AS cnt,
            row_number() OVER (PARTITION BY mtu_bucket ORDER BY cnt DESC) AS rn
        FROM base_data
        WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
        GROUP BY mtu_bucket, wsize
    )
    WHERE rn <= 5
    GROUP BY mtu_bucket
),
top_scales AS (
    SELECT
        mtu_bucket,
        groupArray((scale, cnt)) AS top_scales
    FROM
    (
        SELECT
            CASE
                WHEN mtu = 1500 THEN 1500
                WHEN mtu = 1440 THEN 1440
                WHEN mtu = 1420 THEN 1420
                WHEN mtu = 1380 THEN 1380
                WHEN mtu > 1500 THEN 1501 + intDiv(mtu - 1501, 100) * 100
                ELSE intDiv(mtu, 20) * 20
            END AS mtu_bucket,
            scale,
            count() AS cnt,
            row_number() OVER (PARTITION BY mtu_bucket ORDER BY cnt DESC) AS rn
        FROM base_data
        WHERE mtu IS NOT NULL AND wsize IS NOT NULL AND scale IS NOT NULL
        GROUP BY mtu_bucket, scale
    )
    WHERE rn <= 5
    GROUP BY mtu_bucket
)
SELECT
    CASE
        WHEN mtu_bucket IN (1500, 1440, 1420, 1380) THEN toString(mtu_bucket)
        WHEN mtu_bucket > 1500 THEN concat(toString(mtu_bucket), '-', toString(mtu_bucket + 99))
        ELSE concat(toString(mtu_bucket), '-', toString(mtu_bucket + 19))
    END AS mtu_range,
    CASE
        WHEN mtu_bucket = 1500 THEN 'Standard Ethernet'
        WHEN mtu_bucket = 1480 THEN 'Likely PPPoE (e.g., 1492)'
        WHEN mtu_bucket = 1460 THEN 'Likely DS-Lite/GRE Tunnel'
        WHEN mtu_bucket = 1440 THEN 'Likely Mobile LTE/5G (e.g., 1450) / WireGuard over IPv4'
        WHEN mtu_bucket = 1420 THEN 'WireGuard over IPv6'
        WHEN mtu_bucket = 1400 THEN 'Likely OpenVPN / Mobile'
        WHEN mtu_bucket = 1380 THEN 'Likely OpenVPN / WireGuard over DS-Lite / Mobile'
        WHEN mtu_bucket = 1300 THEN 'Likely Mobile LTE/5G configured'
        WHEN mtu_bucket = 1280 THEN 'IPv6 Minimum'
        WHEN mtu_bucket > 1500 THEN 'Jumbo Frame'
        ELSE 'Other'
    END AS mtu_attribution,
    high_latency_count,
    normal_latency_count,
    round(high_latency_count / (high_latency_count + normal_latency_count), 2) AS high_latency_ratio,
    top_wsizes,
    top_scales,
    avg_real_wsize
FROM main_aggs
LEFT JOIN top_wsizes USING (mtu_bucket)
LEFT JOIN top_scales USING (mtu_bucket)
WHERE (high_latency_count + normal_latency_count) > 10000
ORDER BY mtu_bucket
LIMIT 50 FORMAT Vertical

Why Jumbo Frames Matter

Jumbo frames (MTU values greater than 1500 bytes) are a useful edge case in MTU fingerprinting. These frames, typically ranging from 9000-9216 bytes, are primarily used in high-performance computing environments, data centres, and enterprise networks where throughput optimisation is important.

When we detect jumbo frame MTUs in our analysis, they often indicate:

Enterprise Users: Corporate networks frequently enable jumbo frames for internal communications
Data Centre Traffic: Cloud services and CDNs often use jumbo frames between their infrastructure
High-Performance Applications: Video streaming, large file transfers, and backup operations can benefit from larger frame sizes
Network Misconfiguration: Jumbo frames sometimes appear because of network equipment misconfiguration

The presence of jumbo frames can help distinguish consumer and enterprise traffic, adding useful context for traffic classification and security analysis.

Practical Use Cases and Applications

MTU fingerprinting is useful across several security and operational domains:

Security Applications

VPN Detection for Compliance: Organisations can identify employees bypassing corporate network policies with personal VPNs, supporting compliance with data governance requirements.

Bot Traffic Classification: Automated traffic from residential proxy networks often shows consistent MTU patterns that differ from genuine residential users, improving bot detection.

Threat Intelligence Enhancement: Correlating MTU patterns with other indicators helps build broader threat profiles and improves attack attribution.

Network Operations

Performance Optimisation: Understanding the MTU distribution of your user base helps optimise content delivery and reduce fragmentation-related performance issues.

Infrastructure Planning: MTU analysis reveals the underlying network technologies your users employ, informing CDN placement and capacity planning decisions.

Quality of Service: Different MTU patterns correlate with connection quality, enabling proactive support for users on constrained networks.

Business Intelligence

Market Analysis: Geographic and demographic patterns in MTU distribution reveal technology adoption trends and market characteristics.

User Experience Optimisation: Identifying users on mobile or constrained networks enables adaptive content delivery and interface optimisation.

Dynamic Analysis vs Static IP Databases

MTU fingerprinting is a dynamic signal, which makes it useful alongside static IP reputation databases. It has several practical advantages:

Real-Time Adaptation

Static IP databases go stale. A residential IP address might be flagged as malicious based on historical activity, but MTU fingerprinting analyses the current network configuration. This dynamic approach captures the infrastructure being used at the moment of connection, providing more accurate and timely intelligence.

Treat the value as path evidence

An inferred MTU can narrow the possible network paths behind a connection. It cannot prove that a user is on a particular VPN, mobile carrier or proxy. Different tunnels can produce the same value, endpoints can set their own MTU, and the capture point may not see the smallest link on the complete path.

That makes MTU useful beside IP, ASN, TLS, HTTP and behavioural evidence. It can help explain why two requests that share an IP look different, or why requests from rotating IPs still appear to use the same tunnel shape. Whether it improves a decision—and whether it changes false positives—has to be measured on local traffic.

Where MTU fits

MTU fingerprinting turns TCP handshake metadata into a supporting signal, not a network identity. Record the observed TCP value, inference method and capture point so an operator can see why a label was suggested.

Start by logging the signal on one route. Compare it with known mobile, residential, corporate and VPN traffic before it affects enforcement. If the cohorts overlap too heavily, keep the value for investigation rather than forcing it into a block rule.

How Bots Contaminate Your A/B Testing Results and Marketing Strategy

2025-01-15T13:00:00+11:00

Marketing teams invest heavily in A/B testing to optimise websites, campaigns and user experiences. These tests inform decisions about design, content and functionality. Bot traffic undermines the validity of those decisions.

The Scale of Bot Traffic

Our research shows that bots generate half of all internet traffic. This includes legitimate bots, such as search engines, and malicious bots conducting attacks. For marketing teams, this creates a direct problem: your A/B tests include manipulated responses.

Bot traffic skews test results in multiple ways. Bots do not interact with different test variants the way real users do. They follow programmed patterns rather than genuine user preferences. This contaminates the data marketing teams use to make decisions about website changes, campaign optimisation and user experience improvements.

The Impact on Marketing Strategy

Contaminated A/B test results lead to flawed strategic decisions. Marketing teams might optimise for bot behaviour rather than real user preferences. This affects several areas of strategy:

Website Design - Teams select layouts and features that perform well with bots rather than humans. Navigation flows optimise for automated traffic patterns instead of genuine user journeys. Content decisions target bot consumption rather than human engagement.

Campaign Optimisation - Bot interactions corrupt conversion rate data. Teams allocate budgets based on manipulated performance metrics. Campaigns end up catering to bot behaviour instead of real customers.

User Experience - Interface changes are skewed by bot behaviour patterns. Feature development prioritises elements that score well with automated traffic. Content strategy aligns with bot consumption rather than human needs.

The Residential Proxy Challenge

Residential proxy networks create a specific challenge for A/B testing. These proxies route bot traffic through real consumer IP addresses, making automated traffic look legitimate. Traditional bot detection methods struggle to identify this traffic.

Our research demonstrates that standard IP intelligence services miss up to 96% of residential proxy traffic. This means marketing teams include large amounts of proxy-based bot traffic in their test results without realising it.

Residential proxies mask sophisticated bot behaviour that mimics real users. The bots rotate through different residential IPs to avoid detection. They generate clicks, page views and conversions that appear genuine but represent automated rather than human interactions.

Protecting Your Tests

Marketing teams need protection measures that keep A/B test results valid. This requires a multi-layered approach to identifying and filtering bot traffic:

Detection starts with continuous monitoring of traffic patterns. Teams track user behaviour to identify automated interactions. This includes analysing click patterns, page view sequences and conversion flows that indicate bot activity.

Prevention requires sophisticated bot management capabilities. Our Bot Management solution blocks automated traffic while allowing real users to participate in tests. The system detects and filters residential proxy traffic so test data comes from genuine visitors.

Protection extends to API endpoints that support A/B testing infrastructure. Our API Security capabilities prevent bots from manipulating test data through direct API access. This ensures the integrity of test results across all interaction channels.

Making Informed Decisions

Understanding bot traffic helps marketing teams protect their investment in A/B testing. Data analysis must start by filtering bot interactions from genuine test results. Teams measure genuine user engagement rather than combined human and bot behaviour. This enables accurate assessment of test variants based on real user preferences.

Strategic planning improves once teams understand the impact of bots. Marketing decisions align with genuine user needs rather than artificial interactions. Campaign optimisation targets real customer segments instead of bot characteristics. Feature development prioritises elements that resonate with humans rather than automated traffic.

Budget allocation becomes more effective when based on clean data. Teams invest in changes that improve real user experiences rather than bot interactions. Campaign spending targets channels with verified human traffic. Development resources focus on features that drive genuine engagement.

Taking Action

Marketing teams must implement three key measures to protect A/B testing:

First, deploy comprehensive bot management to identify and block automated traffic. This forms the foundation for valid test results by ensuring participation from real users.

Second, implement residential proxy detection to prevent sophisticated bots from corrupting test data. This ensures traffic comes from genuine users rather than proxy networks.

Third, protect API endpoints that support testing infrastructure. Our Traffic Control solution provides protection across web and API interfaces.

Conclusion

Bot traffic undermines A/B testing and can push marketing teams towards flawed decisions. Past results may already contain bot interactions. The priority is to detect and filter that traffic before it shapes the next test, campaign or product decision.

Anti-Detect Browsers

2025-01-15T10:00:00+11:00

Anti-detect browsers matter to defenders because they attack the assumptions behind browser trust. Many bot and fraud controls look for consistency between the browser, network, session, and behaviour. Anti-detect tooling is designed to make automated or repeated activity look more like separate ordinary browser sessions.

This article is not a guide to using those tools. The defensive question is simpler: when a browser tries to look ordinary, what can still be observed safely, and how should that evidence affect a request decision?

Why They Create Risk

Anti-detect browsers are often discussed as a browser-fingerprinting problem, but the risk is wider than that. The same traffic may also involve residential proxies, credential lists, automation, and API requests that never run browser-side checks. A login attempt, account creation flow, product scrape, checkout request, or mobile API call may look valid at the protocol level while still being part of an automated campaign.

The hard part is that some signals are genuinely ambiguous. A changed browser, a new device, a shared network, or a privacy tool does not prove abuse. A defensive system has to treat those observations as risk inputs, not as standalone verdicts.

Browser Consistency Is Evidence, Not Identity

Anti-detect tooling tries to make browser-reported attributes look internally consistent. That weakens simple checks that only ask whether the browser appears plausible. Defenders need a broader view: does the claimed browser line up with the network stack, TLS and HTTP behaviour, session history, cookie continuity, route sequence, response-code pattern, and recent account behaviour?

That does not mean a fingerprint identifies a person. Fingerprints classify software, client behaviour, and connection characteristics. They can help separate likely automation from ordinary traffic, but they need to be combined with route, account, proxy, and behavioural context. The result should be a risk classification with evidence attached, not an unexplained block.

Residential Proxies Change the Decision

Residential proxies are a common companion signal because they make requests appear to come from consumer networks. That creates a false-positive problem. Real customers also use shared residential, mobile, office, carrier-grade NAT, and public Wi-Fi networks. Blocking every suspicious or shared source would damage legitimate traffic.

The safer approach is to use residential proxy detection as one input in the decision. A proxy signal on a public content page may be logged. The same signal on repeated login failures, account creation, checkout abuse, or sensitive APIs may justify a challenge, rate limit, or block. Context changes the action.

The API Gap

Browser-side checks are weakest where the browser is not present. Mobile apps, partner integrations, token routes, and direct API clients may not expose the same JavaScript or browser evidence that a web page does. Attackers do not need a convincing browser if the target workflow accepts valid-looking API requests.

That is why anti-detect risk belongs in the wider application security model. API routes need method, schema, authentication, token, request cadence, response-code, account, and bot context. If the only signal available is an IP address, the decision will be too blunt.

Observable Signals Defenders Can Use

The useful evidence is usually the mismatch between what the request claims to be and how it behaves over time. A browser may look plausible on one request, but the wider pattern can still show automation: repeated attempts across accounts, route sequences that normal users do not follow, cache-miss pressure on expensive pages, unusual response-code loops, or browser and network characteristics that drift in ways ordinary clients rarely do.

Bot Management works best when it combines these signals rather than chasing a single magic detector. IP intelligence, proxy classification, network and browser fingerprints, route-aware rates, API state, WAF findings, and behaviour should all feed the same action vocabulary: allow, challenge, rate limit, block, log, or review.

Safer Defensive Response

The defensive response should be proportionate. High-confidence exploit traffic can be blocked quickly. Uncertain browser or proxy evidence may be better challenged, rate limited, or logged until the pattern is clearer. Sensitive routes should have tighter policy than public content. Account-impacting actions should preserve enough evidence for review.

This is especially important for support teams. If a real customer is challenged or blocked, operators need to see which signal drove the action and which route was involved. Without that record, anti-bot policy becomes a black box.

Final Thoughts

Anti-detect browsers are a practical problem because they reduce the value of simple browser checks. They do not make traffic invisible. They leave request-path evidence in network behaviour, route sequences, account activity, API usage, proxy signals, and response patterns.

The right goal is not to identify a person from a fingerprint or to block every unusual browser. The goal is to classify risk with enough context to choose a safe action at the edge, then keep the evidence available for tuning and review.

The Hidden Cost of Click Fraud

2025-01-14T13:00:00+11:00

Marketing organisations are losing money to automated clicks and fake impressions. These attacks drain advertising budgets and corrupt the data CMOs rely on for strategic decisions. The lost money cannot be recovered, but understanding the scale and mechanics of click fraud helps marketing teams protect future investment and optimise campaigns.

The Scale of Click Fraud

Click fraud now consumes 40% of digital advertising budgets through fake clicks and impressions that never reach real customers. It affects every digital marketing channel, from pay-per-click and display advertising to social media campaigns, retargeting, and video advertising. The damage goes beyond direct financial loss, because it also corrupts the metrics teams use for decision-making.

Our research on bot traffic shows the percentage of fraudulent clicks continues to rise each quarter. Marketing teams that ignore this threat base their strategies on flawed data, which leads to misallocated resources and weaker campaign performance.

How Bots Generate Fake Clicks

Automated bots generate clicks and impressions at scale across digital advertising platforms. These programs target competitor advertisements to drain marketing budgets through fake clicks. They create artificial impressions that inflate metrics and send false engagement signals. Bots also manipulate bidding algorithms and skew attribution data, leading to misallocated advertising resources.

Modern bots use more advanced techniques to evade standard security controls. They mimic human behaviour patterns and rotate through different IP addresses to avoid detection and blocking.

The Residential Proxy Challenge

Residential proxies create a significant obstacle for click fraud detection systems. These proxy services route bot traffic through IP addresses assigned to real consumers' homes and devices, making fraudulent traffic look legitimate to traditional anti-bot tools.

Residential proxy networks build their IP pools through multiple channels. They partner with consumer VPN services, distribute browser extensions, embed code in mobile applications, and in some cases exploit compromised devices. This mix gives proxy operators access to millions of residential IP addresses.

Traditional IP reputation services fail to identify this proxy traffic. Our research demonstrates these services miss up to 96% of residential proxy traffic, leaving advertising campaigns exposed to fraud through these channels.

Impact on Marketing Strategy

Click fraud undermines three core areas of marketing decision-making. First, it distorts campaign performance metrics through false click-through rates and inflated impression counts. The fraud creates skewed conversion data and engagement metrics that mask true campaign performance.

In budget allocation, click fraud wastes marketing spend on non-existent users while reducing campaign ROI. Artificially inflated acquisition costs lead marketing teams to misallocate resources across channels and campaigns.

Strategic planning suffers when data is contaminated across multiple dimensions. A/B testing results become invalid when bots generate fake interactions. Geographic and demographic data lose accuracy due to proxy traffic. Competitive intelligence becomes unreliable as bot activity masks true market dynamics.

Marketing teams that base decisions on corrupted data take on significant risk. Their optimisation efforts target bot behaviour instead of real users. Campaign budgets flow to channels dominated by fraud. Strategic initiatives fail because decisions are based on artificial metrics rather than genuine customer behaviour.

Protecting Your Marketing Investment

Lost money from click fraud cannot be recovered, so marketing teams need protection measures for future investment. Detection forms the first line of defence through continuous monitoring of traffic patterns and IP reputation analysis. Teams track user behaviour to identify suspicious patterns that indicate fraud.

Prevention requires a multi-layered security approach. Marketing teams need systems that block known bot networks and detect residential proxies attempting to generate fake clicks. These controls validate real user traffic and filter out fraudulent clicks before they affect campaigns.

Campaign optimisation becomes more useful once fraud protection is in place. Teams can adjust targeting parameters based on genuine user data and reallocate budgets to channels with verified traffic. This supports updates to bidding strategies and refinement of audience segments based on real engagement.

Our Ad Fraud Protection solution protects marketing investment by blocking bot traffic, detecting residential proxies, and validating real users. This helps ensure ad spend reaches genuine customers rather than fraudulent clicks.

Making Informed Decisions

Understanding click fraud changes how marketing teams analyse data and plan campaigns. Data analysis starts with identifying corrupted metrics in campaign reports. Teams must filter bot traffic from their analytics to measure real user engagement. This enables tracking of true campaign performance based on human interactions.

Budget planning improves once teams understand the scale of click fraud. Marketing teams can allocate resources to channels with verified human traffic. This focus on real users optimises campaign spend and improves return on investment across marketing initiatives.

Strategy development depends on clean, accurate data. Teams make decisions based on genuine user behaviour rather than bot interactions. Campaign planning targets real audience segments with messages that resonate. Performance measurement reflects actual results rather than artificial engagement.

Taking Action

Marketing teams need protection measures across three key areas to secure their investments. First, bot protection forms the foundation through deployment of bot management systems. These systems block automated traffic while validating real users and monitoring for suspicious patterns.

The second protection layer focuses on residential proxy detection. Teams implement proxy detection to identify and block proxy networks. This helps ensure traffic comes from real IP addresses and prevents fraud through residential proxies.

The third component centres on protecting ad spend through traffic monitoring. Teams implement systems to block fraudulent clicks and validate impressions. This enables tracking of real engagement from genuine users.

Our Traffic Control solution combines these protection measures to help marketing teams secure their investments and base decisions on real user data.

Conclusion

Click fraud threatens marketing budgets and corrupts campaign data. Lost money cannot be recovered, but understanding and preventing fraud helps marketing teams protect future investment and make better decisions.

Residential Proxies - The Growing Threat to Ad Campaigns

2024-12-30T00:00:00+11:00

Digital advertising fraud costs organisations $42 billion annually through fake clicks and fake impressions. The growth of residential proxy networks has changed how this fraud reaches campaigns: bot traffic can now hide behind legitimate residential IP addresses, putting it outside the reach of many traditional checks.

Hiding in the crowd

Residential proxies make bad traffic harder to separate from real visitors. Unlike data centre IPs that traditional tools can often detect, residential proxies hide behind real households' internet connections. This means the traffic appears to come from genuine users in your target market. When a residential proxy network operates from Sydney suburbs to attack an Australian campaign, existing protection systems can be fooled into treating it as authentic local traffic.

The impact extends beyond direct financial losses. Your analytics may show engagement from what appears to be your target demographic, while the activity is bot traffic masquerading as potential customers. This contaminated data can push marketing strategy in the wrong direction and waste retargeting spend. Competitors can also use fake clicks to drain your budget while gathering intelligence on your campaigns.

Bad data then compounds the spend problem. Once bots are counted as engaged prospects, reporting and optimisation start from the wrong signal. The result is not only wasted media spend, but poorer decisions built on traffic that should never have been treated as customer intent.

A growing threat

The residential proxy industry continues to expand. Services now offer millions of residential IPs with precise geographic targeting capabilities. They rotate IPs automatically and match real browser fingerprints. Without specialised detection methods, the traffic can become indistinguishable from genuine users.

This is a budget problem, not just a technical one. Each day without protection means 30-40% of your ad budget feeds bot networks instead of reaching customers. The corrupted analytics drive decisions that compound these losses. As residential proxy services grow more sophisticated, basic controls fall further behind.

Traditional IP reputation and rate limiting fail against this distributed threat because the IP addresses are not obviously suspicious. Protection requires advanced network fingerprinting that looks beyond IP addresses. Peakhour's Ad Fraud Protection analyses subtle patterns in how residential proxies connect and behave, and detects the signs of proxy traffic that other solutions miss.

Knowledge is power

Peakhour integrates this protection with your existing ad platforms to stop fraud before it affects your campaigns. Our customers have reduced wasted ad spend by 35% while improving campaign performance through cleaner analytics. The system adapts as threat techniques change, so detection keeps pace with new residential proxy methods.

Residential proxies have changed ad fraud because traffic that appears local and legitimate may mask sophisticated bot networks. Protecting your campaigns requires detection that goes beyond IP addresses and treats residential proxy behaviour as its own signal. Contact us to learn how we can help secure your ad spend against residential proxy networks.

Next-Generation Application Security Defence Strategies

2024-11-15T14:00:00+11:00

As I look at recent cyber threat activity, the pattern is clear enough: AI is no longer only a defensive tool. Attackers are using it to probe, adapt, and automate application-layer attacks.

One recent incident made that plain. Our threat detection systems identified a series of probes against a client's infrastructure. These were not the typical brute-force attempts we are used to blocking. The attack patterns changed in real time, adapted to our defences, and probed for weaknesses in a way that pointed to AI-driven automation.

The individual attempts were not the main concern. What mattered was how the attack system learned and adjusted its approach. When we blocked one vector, it shifted to another. When we implemented rate limiting, it distributed its attempts through residential proxies. The attack showed a common trait of AI systems: rapid iteration and learning from failure.

This change in attack methodology puts real pressure on the traditional security model. Static defences, including controls that looked strong only months ago, are easier to route around. They might stop obvious threats, but more capable AI-powered attacks can keep testing the edges until they find a path.

The threat landscape has shifted in three practical ways. First, AI enables attacks to adapt and evolve in real time. Second, residential proxies give attackers a distributed network of IP addresses that appear legitimate, making traffic origin verification much harder. Third, AI can analyse and mimic legitimate user behaviour patterns closely enough to bypass traditional bot detection.

These changes require a change in defence strategy. Identifying and blocking known attack patterns still matters, but it is no longer enough on its own. We need systems that can anticipate and adapt to new threats as quickly as they emerge.

In our security operations, we've begun implementing what we call "contextual defence dynamics." The approach moves beyond simple pattern matching to analyse the intent and behaviour behind each request. We examine not just what a request does, but how it fits into broader patterns of behaviour and what it might indicate about the attacker's objectives.

That approach has already proved useful. When we implemented contextual defence dynamics for a major e-commerce client, we identified and blocked an AI-powered credential stuffing attack that had evaded traditional detection methods for weeks. The attack used residential proxies to distribute its attempts and mimicked human behaviour patterns, but our system identified subtle anomalies in its timing and response patterns.

That case highlighted a useful point: while AI-powered attacks grow more sophisticated, they still exhibit patterns. Those patterns may not appear in individual actions, but they do appear in broader behaviour and objectives. By shifting our focus from blocking specific actions to understanding and responding to these broader patterns, we can maintain effective defences even against evolving threats.

This approach requires a different way of thinking about security. We must move from a model of static defences to one of dynamic response. Our security systems must learn and adapt as quickly as the threats they face. This means implementing machine learning systems that can identify new attack patterns, updating defence strategies in real time, and maintaining awareness of emerging threat vectors.

The implications extend beyond technical implementation. Organisations need to treat security budgets and strategies as ongoing commitments, not one-off purchases. The era of "set and forget" security solutions has ended. Continuous adaptation and review now sit at the centre of effective defence.

I expect this arms race to keep accelerating. AI will continue to enhance both attack and defence capabilities. The organisations that maintain strong security will be those that accept this dynamic and build their defences around continuous adaptation.

For security professionals, this means developing new skills and approaches. We must understand not just the technical aspects of security, but the patterns of attack and defence that emerge in AI-driven systems. We must build systems that can learn and adapt, and we must be prepared to change strategy as the threat landscape evolves.

The security arms race has entered a new phase. The advantage will not sit with the strongest static defences alone, but with teams that can adapt and evolve their protection strategies in real time. The focus must shift from building walls to creating intelligent, adaptive defence systems that can match the sophistication of AI-powered threats.

This shift in security thinking is practical, not theoretical. The threats we face are becoming more capable, and defensive tooling is improving as well. The important step is recognising the change and adapting how we build, operate, and review application security controls.

Your Anti-Fraud Residential Proxy Detection Sucks

2024-10-04T13:00:00+10:00

Online fraud is big business: account takeovers, chargebacks, scams, even romance scams. It costs businesses billions of dollars every year.

A common way websites fight it is to use an anti-fraud service to calculate the risk of a transaction. Most teams get this intelligence from a third-party service, either through an API or a plugin.

For online stores, ecommerce fraud prevention has to protect checkout and account flows without punishing real customers.

One of the major signals these services use is IP reputation. IP reputation tries to answer questions like:

Is the order coming from a datacentre?
Is it coming from a country other than your target audience?
Is the IP address a known VPN?
Is it a known TOR exit node?
Have lots of fraudulent orders come from this IP address in the past?

Until recently, these services gave teams a useful way to calculate fraud risk from an IP address.

Not anymore.

Fraud traffic has shifted in recent years, away from VPNs and TOR and toward residential proxies. These same anti-fraud services claim they can detect residential proxies, but what if the services many businesses rely on are falling well short?

The results are bad enough that they deserve a blunt look.

The Shocking Truth: Our Results

We took 25 IP addresses that had just been used as residential proxies in an attack on one of our clients, and within 5 minutes of detection ran them through some of the most popular IP intelligence services. The results are not going into anyone's marketing deck.

Here's a summary of our findings:

Service	Detected Proxies	Accuracy
Maxmind	0/25	0%
IP Quality Score	6/25	24%
Seon	1/25	4%
ProxyCheck.io	0/25	0%
ip2proxy	1/25	4%

The best performer in our test, IP Quality Score, detected only 24% of the proxies. The others ranged from 0% to 4%.

Why Your Residential Proxy Detection Service is Failing You

So why are these services performing so poorly? To understand it, we need to look at how proxy usage and detection have changed.

The Good Old Days of Proxy Detection

In the recent past, detecting proxies was much easier. Fraudsters primarily used:

TOR networks
VPN services
Data center proxies

These were relatively static targets. They were tied to a single, stationary IP, or IP ranges. Listing them in IP block lists was straightforward.

The Rise of Residential Proxies: A New Breed of Threat

Now we need to talk about residential proxies, the new go-to tool of fraudsters and scammers. These are not just a new label for old proxies. They behave differently.

What Are Residential Proxies?

Residential proxies come from IP addresses assigned to real residential services by Internet Service Providers (ISPs). These can be:

Home computers
Mobile phones
Tablets
IoT devices

Unlike data center proxies, which use IP addresses from hosting companies, residential proxies use IPs that look just like any other home or mobile user. They have become the tool for avoiding security controls on websites in the last 2-3 years, and they are causing all sorts of headaches for website owners.

How Are Residential Proxy Networks Formed?

This is where the problem starts:

Compromised Devices: Malware can turn innocent devices into proxy endpoints without the owner's knowledge.
Incentivised Programs: Some companies offer users benefits (like free VPN services) in exchange for using their device as a proxy endpoint. Hola VPN and Brightdata are prominent examples.
APP SDKs Quite often, proxy providers will incentivise app developers to include their proxy toolkit in their apps. The user is totally unaware that their device's internet connection is now being resold.

So your personal device, be it a computer or phone, could have its internet connection used to carry out a crime without you knowing. The police could come knocking on YOUR door one day.

Why Are They So Dynamic?

Since the proxy is formed by reusing the internet connection of a device, it is inherently much more dynamic than a proxy formed on a server.

Device Mobility: A mobile phone can connect from home Wi-Fi, then a coffee shop, then a cellular network – all in one day.
ISP IP Rotation: Many ISPs dynamically assign IP addresses, changing them periodically.

Depending on the type of fraud being carried out, the attacker might also rotate the device being used, popping out of a different location. Also, due to the way these proxies are formed, i.e. via an app on a computer or phone, that particular exit point on the proxy network might depend on that app being open.

This dynamic nature is what makes residential proxies so hard to detect using traditional methods.

Shared IPs: The Needle in the Haystack Problem

Residential proxy IPs are not just dynamic. They are typically shared. This means that a single IP address could be used by both legitimate users and proxy traffic:

ISP IP Pools: Internet Service Providers often use large pools of IPs that are dynamically assigned to users. This means that an IP used by a proxy one minute could be assigned to your grandmother's iPad the next.
Carrier-Grade NAT (CGN): Mobile carriers frequently use CGN, which can make hundreds or thousands of users appear to come from the same IP address.
Compromised Routers: A single compromised home router could serve both the legitimate traffic of the homeowner and proxy traffic from the attacker.

If you simply blocked any IP that shows proxy behavior, you would end up blocking legitimate users too.

Why Traditional Methods Are Failing (Revisited)

Now that we understand residential proxies better, let's revisit why old-school detection methods are not enough.

1. Port Scanning

Traditional proxy detection often relies on scanning for open proxy ports. Here's a simple port scanner:

import socket

def port_scan(ip, port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    result = sock.connect_ex((ip, port))
    sock.close()
    return result == 0

# Example usage
ip = "123.45.67.89"
proxy_ports = [80, 8080, 3128]  # Common proxy ports

for port in proxy_ports:
    if port_scan(ip, port):
        print(f"Port {port} is open - potential proxy detected")

Why it fails: Residential proxies don't typically have these ports open. They route traffic through standard web ports, making them indistinguishable from normal traffic.

2. Honeypots

Honeypots try to lure and identify proxy traffic.

Why it fails: Sophisticated residential proxy networks can identify and avoid known honeypots. Plus, since they're using real residential IPs, even if they do hit a honeypot, the IP itself isn't a reliable indicator of proxy usage.

3. Client-Side Detection

Detection services may also try to detect proxies by executing Javascript in the browser and checking the result for inconsistencies. These are the common techniques.

3.1 WebRTC Leak

WebRTC can sometimes reveal a user's true IP address:

function detectRealIP(callback) {
    var RTCPeerConnection = window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection;
    var pc = new RTCPeerConnection({iceServers:[]}), noop = function(){};
    pc.createDataChannel("");
    pc.createOffer(pc.setLocalDescription.bind(pc), noop);
    pc.onicecandidate = function(ice) {
        if(!ice || !ice.candidate || !ice.candidate.candidate) return;
        var myIP = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/.exec(ice.candidate.candidate)[1];
        pc.onicecandidate = noop;
        callback(myIP);
    };
}

detectRealIP(function(ip) {
    console.log("Your real IP address is: " + ip);
});

3.2 Geolocation Inconsistencies

Comparing IP-based geolocation with browser-reported location.

navigator.geolocation.getCurrentPosition((position) => {
  const browserLat = position.coords.latitude;
  const browserLong = position.coords.longitude;
  // Compare with IP-based geolocation from server
});

3.3 DNS Leaks

Check whether DNS requests are routed through the proxy or are leaking:

const image = new Image();
const uniqueDomain = `test-${Date.now()}.example.com`;
image.src = `http://${uniqueDomain}/pixel.gif`;
// Monitor DNS requests server-side to detect leaks

3.4 Browser Fingerprinting

Check whether there are inconsistencies with the browser, e.g. timezone, and the geolocation of the IP address

const fingerprint = {
userAgent: navigator.userAgent,
screenResolution: `${screen.width}x${screen.height}`,
colorDepth: screen.colorDepth,
timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
plugins: Array.from(navigator.plugins).map(p => p.name),
// ... other characteristics
};
// Analyze fingerprint for proxy indicators

Why these techniques fail

Proxy services can work around all of these methods. Many browsers now allow users to disable WebRTC or use extensions that prevent this leak. Some residential proxy services are sophisticated enough to handle WebRTC requests without leaking the real IP.

Finally, relying on client-side detection means: * Your detection can be reverse engineered and bypassed. * You've already served the content the attacker wants. * It requires Javascript execution, something that won't always be available, for instance on an API.

4. Threat Intelligence

Threat intelligence involves maintaining databases of known proxy IP addresses:

import requests

def check_ip_threat_intel(ip):
    api_key = "your_api_key_here"
    url = f"https://api.threatintelligence.com/v1/ip/{ip}?key={api_key}"
    response = requests.get(url)
    if response.status_code == 200:
        data = response.json()
        return data.get('is_proxy', False)
    return False

# Example usage
ip = "123.45.67.89"
if check_ip_threat_intel(ip):
    print(f"{ip} is a known proxy according to threat intelligence")

Why it fails: As our results show, threat intelligence databases are struggling to keep up with the dynamic nature of residential proxies. By the time an IP is identified and added to a database, it may no longer be in use as a proxy.

Why IP-Based Blocking Is No Longer Enough

Given the shared nature of IPs in the age of residential proxies, simply identifying and blocking "bad" IPs is too blunt. Here's why:

False Positives: Blocking an IP used by a proxy might also block legitimate users sharing that IP.
Ineffectiveness: Proxies can quickly switch to new IPs, so IP-based blocking turns into a chase.
Collateral Damage: You might end up blocking entire ISPs or mobile carriers, cutting off large swaths of legitimate users.

The practical failure is customer friction. A checkout, login, or account recovery flow cannot treat every residential or mobile network as hostile. Teams need enough request context to choose a proportionate response: log the signal on a low-risk page, challenge a suspicious account change, rate limit repeated failures, or block only when proxy evidence lines up with stronger abuse indicators.

The same problem shows up on APIs and partner integrations. A partner batch job, mobile carrier, or shared office network can look noisy without being hostile. A compromised key can look legitimate until it starts hitting expensive routes. Good review paths keep the route, account or API key, request rate, fingerprint, and recent outcomes together so the answer is not just "block the IP" or "allow everything."

This is where proxy detection stops being a lookup problem and becomes an operating problem. The team needs to know which route was hit, what account or session was involved, whether the request matched normal behaviour, and what the enforcement cost would be if the signal was wrong. That is the difference between reducing abuse and quietly pushing good customers into support. For a deeper treatment of that tradeoff, see the guide to customer friction and false-positive measurement.

The Need for Connection-Level Detection

Instead of focusing only on IPs, we need to look at the connections themselves. Here's what this means:

Deep packet inspection: Analyses traffic patterns and characteristics beyond surface-level indicators.
Protocol behaviour analysis: Identifies subtle anomalies in how network protocols are implemented across the proxy chain.
TLS/TCP fingerprinting: Examines characteristics of TLS handshakes to detect proxy usage.
Timing analysis: Measures minute differences in network latency that can indicate the presence of a proxy.

Final Thoughts

Proxy usage has evolved, and detection methods need to keep up. Simple IP-based blocking and static lists of "bad" addresses are no longer enough. They still have a place, but they cannot be the whole answer.

Modern residential proxy detection has to evaluate the live request: IP context, connection behaviour, fingerprints, route, account state, request rate, and recent outcomes. On a low-risk page that may only justify logging. On login, signup, checkout, password reset, API key creation, or account recovery, the same signal may justify a challenge, hold, rate limit, or block.

Peakhour's residential proxy detection is built for that request-path decision. The point is not to label every residential IP as bad. The point is to give operators enough evidence to act when proxy use lines up with account abuse, fraud, scraping, or automated traffic.

If you're still treating IP reputation as the main answer, you're already behind. It's time to stop blocking IPs and start understanding the request.

Want a demo of our residential proxy detection? Contact us for a live demo of our service.

Managing Bots For Application Security

2024-09-15T00:00:00+10:00

This guide separates bot management into three maturity levels: basic, intermediate, and advanced. The point is not to rank feature lists. It is to understand what kind of bot decision each level can safely make on the request path.

Bots now target revenue, data, accounts, inventory, APIs, and origin capacity. Some are obvious crawlers. Others run credential stuffing, account creation, scraping, inventory hoarding, click fraud, or Layer 7 pressure through traffic that looks close to normal. A useful bot control has to decide whether to allow, challenge, rate limit, block, log, or review a request without punishing legitimate users who happen to share a network or device pattern.

For more on account impact, read our article on the Business Impact of Credential Stuffing.

Basic Protection

Basic bot management is built around visible signals: user-agent checks, simple IP reputation, known bot signatures, and broad rate limits. These controls still have a job. They can manage well-behaved crawlers, block obvious automation, and stop a single noisy source from hammering a site.

The limitation is that basic controls assume the source or header tells most of the story. That breaks down when automation behaves like a browser, rotates infrastructure, or spreads requests across residential and shared networks. A flat IP limit may slow one scraper and still miss a credential attack distributed across many exits. It may also catch real users behind a busy office, mobile carrier, or public Wi-Fi network.

Basic protection is suitable when the risk is low, the main concern is crawler hygiene, and the business can tolerate coarse controls. It is not enough for account protection, high-value scraping targets, or API workflows where abuse can arrive through valid requests.

Intermediate Protection

Intermediate bot management adds more request and client evidence. JavaScript signals, header consistency, cookie behaviour, basic network fingerprints such as TLS fingerprinting, and route-level observations make the decision less dependent on the IP address alone. This level can catch automation that fails to behave like a normal browser or that exposes inconsistencies across requests.

It is a meaningful step up, but it still has limits. Anti-detect browsers and modern automation can keep browser signals plausible for long enough to run a campaign. Residential proxy networks can make source reputation noisy. API requests may not run browser-side checks at all. If the bot system treats browser, route, credential, and API context as separate problems, operators end up tuning several partial controls rather than one decision.

Intermediate protection works for general scraping, noisy automation, and non-persistent abuse. It starts to struggle when attackers adapt, slow down, distribute requests, or target sensitive routes where a small number of requests can cause business harm.

Advanced Protection

Advanced bot management is combined signal decisioning. The difference is not "more techniques" in a checklist. The difference is that IP intelligence, residential proxy status, network and browser fingerprints, route-specific rates, behaviour, credential risk, API context, WAF/WAAP findings, DDoS pressure, and logs feed the same action model.

That context changes the decision. A high request rate on a public image route is not the same as repeated failed logins. A suspicious proxy signal on a cached page is not the same as the same signal on account recovery. A browser fingerprint mismatch may be logged on a low-risk page but challenged when paired with exposed credentials and rapid account switching.

Advanced protection is designed for persistent abuse: credential stuffing, account takeover attempts, scraping at scale, inventory hoarding, fake account creation, API bot traffic, and bot-driven Layer 7 floods. It should support web, mobile, and API traffic, and it should preserve evidence so security, platform, and support teams can see which signal drove an action.

Choosing the Right Level

The right level depends on what the bot can damage. A brochure site may only need crawler management and basic rate limits. An ecommerce site needs protection for search, product, checkout, promotion, and account routes. A marketplace, bank, gaming platform, ticketing site, or API-heavy business usually needs route-aware decisions that combine proxy, fingerprint, credential, account, and behaviour context.

The false-positive risk matters just as much as the attack risk. Shared networks, carrier-grade NAT, privacy tools, corporate egress, and normal browser drift can all make a simple signal look suspicious. A mature bot programme does not block every unusual request. It uses uncertainty to pick safer actions: log, challenge, rate limit, or review before escalating to a block.

Peakhour's View

Peakhour's Bot Management connects bot decisions to the rest of the application security path. Residential Proxy Detection, IP Intelligence, Advanced Rate Limiting, API Security, WAAP/WAF controls, and Log Forwarding all support the same request outcome: allow, challenge, rate limit, block, log, or review with evidence.

That is the practical maturity model. Basic controls handle obvious bots. Intermediate controls add client and request evidence. Advanced controls combine signals into decisions that match the route, risk, and business impact.

Application Security for Financial Services Under CPS 234

2024-07-29T10:00:00+10:00

Recent credential stuffing attacks on prominent Australian retailers like The Iconic and Dan Murphy's have brought this threat into sharper focus. For APRA-regulated entities, these incidents are a reminder that credential stuffing is not only an account takeover issue. It can also trigger assessment and disclosure obligations under Prudential Standard CPS 234 Information Security.

The Rising Tide of Credential Stuffing

Credential stuffing is now common in Australia and globally. These attacks exploit password reuse across multiple sites. Cybercriminals use automated tools to test large volumes of stolen username and password combinations against websites, looking for accounts they can access without authorisation.

The scale is large. According to recent studies, there are over 15 billion stolen credentials circulating on the internet. In 2020 alone, one large content delivery network reported more than 193 billion credential stuffing attacks globally. For Australian businesses, the risk is significant and growing.

The Compounding Threat of Residential Proxies

The use of residential proxies has increased the sophistication and effectiveness of credential stuffing attacks. Residential proxies allow attackers to route their traffic through legitimate residential IP addresses, making automated activity look more like normal user behaviour.

This technique poses several challenges:

Bypassing Traditional Defences: Standard IP-based rate limiting and geo-blocking become ineffective when attacks come from diverse, legitimate-looking IP addresses.
Evading Detection: Traffic from residential proxies is harder to distinguish from genuine user activity, complicating detection efforts.
Scalability: Attackers can distribute their attempts across a large network of proxies, allowing for larger-scale attacks without triggering typical alarm thresholds.
Improved Success Rates: By appearing to come from the same geographic area as legitimate users, these attacks are more likely to bypass location-based security measures.

The Crabby Phenomenon

The emergence of sites like Crabby Cash shows how credential stuffing fits into a broader cybercrime market. These platforms serve as marketplaces for compromised accounts, making it easier for criminals to monetise successful credential stuffing attacks.

Key points about Crabby Cash and similar sites:

Ease of Access: These sites lower the barrier to entry for cybercriminals, providing ready access to compromised accounts.
Rapid Exploitation: Once credentials are verified and listed on these sites, the window for detection and mitigation narrows significantly.
Diverse Targets: The range of compromised accounts often spans multiple industries, including retail, financial services, and entertainment.
Ongoing Threat: The existence of these marketplaces incentivises continuous credential stuffing attempts, creating a persistent threat landscape.

The CPS 234 Disclosure Imperative

The prevalence of credential stuffing attacks, compounded by residential proxies and platforms like Crabby Cash, makes the disclosure requirements in CPS 234 directly relevant.

Paragraph 35 of CPS 234 states:

An APRA-regulated entity must notify APRA as soon as possible and, in any case, no later than 72 hours, after becoming aware of an information security incident that:

(a) materially affected, or had the potential to materially affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers; or

(b) has been notified to other regulators, either in Australia or other jurisdictions.

The existence of sites like Crabby Cash can increase the potential impact of credential stuffing attacks, making them more likely to meet the materiality threshold for disclosure.

A Risk-Based Approach to Disclosure

To manage credential stuffing risk and meet CPS 234 obligations, organisations should take a risk-based approach to detection, mitigation, and disclosure. This involves:

Working with Specialised Providers: Engage with cybersecurity providers who can offer insights into your organisation's exposure and risk levels based on:
- Network fingerprinting
- Levels of breached credential login attempts
- Prevalence of residential proxy traffic as a high-correlating signal of attack
Continuous Risk Assessment: Regularly evaluate the risk posed by credential stuffing attacks, considering factors such as:
- The volume and sophistication of attempts
- The success rate of attacks
- The potential impact on customers and the organisation
Inadequate Defences as a Risk Signal: Recognise that the absence of robust defences against credential stuffing is itself a risk signal. Organisations without advanced bot detection, multi-factor authentication, and behavioural analysis capabilities may face higher risk and should consider this in their disclosure decisions.
Adaptive Disclosure Thresholds: Develop flexible, risk-based thresholds for APRA notification that take into account:
- The current threat landscape
- The organisation's defensive capabilities
- The potential impact of a successful attack

Assessing Materiality in Light of These Threats

When assessing whether a credential stuffing incident meets the materiality threshold for APRA notification, entities should consider:

Scale of the Attack: The number of accounts targeted or compromised.
Success Rate: Whether any accounts were actually breached.
Exposure on Dark Web Markets: If compromised credentials appear on sites like Crabby Cash.
Potential Financial Impact: Both immediate losses and potential future exploitation.
Non-Financial Impacts: Including reputational damage and loss of customer trust.
Broader Systemic Risk: Whether the attack could impact the wider financial system.
Defensive Posture: The adequacy of existing controls and the organisation's ability to detect and mitigate attacks.

Proactive Measures and Controls

To mitigate the risks of credential stuffing attacks, particularly those leveraging residential proxies, APRA-regulated entities should implement robust controls as outlined in CPS 234 and CPG 234:

Contextual Security Approach: Implement a contextual security strategy that considers multiple factors to assess the risk of each login attempt, including device characteristics, user behaviour patterns, and network attributes.
Advanced Bot Detection: Deploy bot management systems capable of identifying automated attempts, even when they come from diverse IP addresses.
Residential Proxy Detection: Utilise specialised residential proxy detection tools to identify and mitigate threats from this increasingly common attack vector.
Multi-Factor Authentication: As suggested in CPG 234, implement MFA for high-risk activities to provide an additional layer of security beyond passwords.
Behavioural Analysis: Use analytics to detect anomalous login patterns that may indicate credential stuffing attempts.
Continuous Monitoring: Implement real-time monitoring systems to quickly identify and respond to potential attacks.
Password Policies: Encourage or enforce the use of unique, strong passwords to mitigate the impact of credential stuffing.
Customer Education: Proactively inform customers about the risks of password reuse and the importance of strong, unique passwords.
Collaboration and Information Sharing: Engage with industry peers and law enforcement to share threat intelligence and effective practices.
Adaptive Authentication: Implement risk-based authentication that adjusts security requirements based on the perceived threat level of each login attempt.

By adopting these measures, particularly a contextual security approach incorporating residential proxy detection, organisations can improve their resilience against credential stuffing attacks and better protect their customers' accounts.

Conclusion

Credential stuffing, residential proxies, and platforms like Crabby Cash make account takeover risk harder to assess and harder to contain. APRA-regulated entities need a proactive, risk-based approach to information security and regulatory compliance.

APRA-regulated entities should treat credential stuffing attacks as more than a technical control problem. They are business risks that may require Board-level attention and, depending on materiality, regulatory disclosure under CPS 234. By implementing preventative measures, maintaining effective incident response capabilities, and keeping clear processes for assessing and reporting incidents, organisations can better protect themselves and their customers from this growing threat.

In this environment, CPS 234 compliance is not only a reporting exercise. It depends on information security controls that protect the organisation, its customers, and the broader financial system before credential stuffing becomes a material incident.

The Australian epidemic of Account Takeover attacks

2024-07-29T10:00:00+10:00

In recent months, credential stuffing attacks have hit a number of Australian businesses, leading to compromised accounts, fraudulent purchases, and customer complaints. The pattern is a reminder that account protection cannot stop at password policy or MFA alone.

A Case Study in Credential Stuffing

Security researcher Jacob Larsen has documented a credential stuffing operation targeting Australian businesses. Larsen's research, detailed in his blog post, describes the activity of a threat actor known as "Crabby," who has sold compromised Australian accounts since July 2023.

Larsen's findings show:

The operation began with a threat actor called "Based" selling compromised accounts via Discord and dedicated websites.
In November 2023, the operation was acquired by "Juicy," a notorious account vendor, and rebranded as "Crabby."
As of May 2024, over 19,000 compromised accounts from various Australian brands were offered for sale.
Low-level fraudsters purchasing these accounts have used them to make unauthorised purchases, often targeting high-value items for resale.

The Crabby operation shows how credential stuffing has moved beyond isolated login attempts. It now includes account marketplaces, low-level fraud buyers, and the challenges businesses face once compromised accounts are monetised.

The Difficulty of Defense

Credential stuffing defence is harder when attacks are spread across residential proxies and kept to single attempts per account.

Residential Proxies: The Invisible Threat

Residential proxies weaken traditional IP-based controls. These proxies use IP addresses assigned to real residential internet connections, so malicious traffic can look like normal customer traffic. That helps attackers bypass simple rate limiting and geolocation checks.

That distribution makes login traffic harder to classify. Signals such as a high volume of attempts from one IP address become less useful when attackers can spread requests across a pool of residential IPs.

Single-Hit Attacks: Precision Strikes

Single-hit attacks are another way attackers avoid noisy patterns. In this approach, each stolen credential is used only once per target site, reducing the chance of detection by traditional rate-limiting or anomaly detection systems.

By limiting each credential to one attempt, attackers avoid controls tuned to repeated login failures. A business can have rate limiting in place and still miss credential stuffing that never crosses those thresholds.

The Mobile API Conundrum

As mobile applications become a primary user interface, credential stuffing also moves into mobile API traffic. Traditional bot protection often relies on JavaScript challenges or browser fingerprinting, which does not apply cleanly to attacks against mobile APIs.

Mobile applications typically communicate with backend services via APIs, bypassing the browser environment where many bot detection techniques run. This creates several challenges:

Lack of JavaScript Execution: Mobile APIs don't execute JavaScript, making it impossible to use browser-based bot detection techniques.
Limited Fingerprinting Capabilities: Standardised mobile API requests make it difficult to distinguish between legitimate user activity and automated attacks based on request characteristics.
Increased Attack Surface: More mobile apps means more potential entry points for attackers, making comprehensive protection more complex.
Authentication Simplification: To improve user experience, mobile apps often use simplified authentication flows, which can create weaker controls against automation.

This gap needs API-centred controls that can assess mobile login behaviour without relying on browser-only signals.

Framing Credential Stuffing as a Business Risk

Credential stuffing should be treated as a business risk, not just an authentication issue. The impact can include refunds, chargebacks, customer support load, reputational damage, and regulatory disclosure work.

Risk Quantification and Disclosure

Risk quantification gives security teams a way to explain credential stuffing in business terms. By applying frameworks like FAIR (Factor Analysis of Information Risk), businesses can:

Quantify the potential financial impact of credential stuffing attacks.
Prioritise security investments based on risk reduction potential.
Communicate the importance of cybersecurity measures to non-technical stakeholders.

CPS 234 in Australia adds a disclosure dimension for regulated entities. Businesses need to protect against credential stuffing and be able to explain their exposure, controls, and mitigation strategy.

The State of Credential Stuffing Defense in Australia

Our recent survey of Australian businesses shows uneven adoption of credential stuffing defences:

While 77% of respondents use Multi-Factor Authentication (MFA), only 40% have implemented bot protection measures.
15% of companies chose not to respond to questions about their security measures, suggesting potential gaps in protection.
Just 29% of businesses check credentials against known breaches, leaving a large window of opportunity for attackers using stolen credentials.
Only 15% of organisations use residential proxy detection, a critical component in identifying and mitigating modern credential stuffing attacks.

These results suggest a gap between how credential stuffing is run now and the controls many Australian businesses have in place.

Recommendations for Enhanced Protection

Based on our analysis and survey results, businesses should review the following controls:

Implement Advanced Bot Protection: Deploy controls that detect and mitigate bot attacks, including attacks using residential proxies.
Enhance Mobile API Security: Use mobile API controls that focus on anomaly detection and behavioural analysis rather than browser-based techniques.
Adopt Risk-Based Authentication: Implement dynamic authentication mechanisms that adjust based on the assessed risk of each session or transaction.
Utilise Breached Credential Databases: Check user credentials against known breach databases and enforce password changes for compromised accounts.
Implement Residential Proxy Detection: Use technology that identifies and mitigates traffic from residential proxy networks. This is a key control for modern credential stuffing attacks.
Apply Advanced Rate Limiting: Utilise device fingerprinting and other identifiers beyond IP addresses to implement more effective rate limiting, particularly for single-hit attacks.
Employ Contextual Security: Use signals such as user behaviour patterns, device characteristics, and historical usage to identify anomalies that may indicate credential stuffing attempts.
Quantify and Communicate Risk: Use frameworks like FAIR to quantify the potential impact of credential stuffing attacks and communicate this risk to stakeholders.
Implement Continuous Monitoring: Deploy real-time monitoring that detects patterns indicative of credential stuffing attacks, and update defences as attack methods change.

These controls address the specific problems created by residential proxies, single-hit attempts, mobile API traffic, and weak credential hygiene. They also reflect the limits of IP-only rate limiting and browser-only bot detection.

Credential stuffing defence works best as a layered programme: bot detection, residential proxy detection, breached credential checks, mobile API coverage, and risk reporting. The practical goal is to stop account takeover attempts earlier, reduce fraud exposure, and give security teams evidence they can act on.

The Challenge of Proxy Detection

2024-07-19T10:00:00+10:00

Our recent survey found that only 15% of Australian organisations use residential proxy detection. That leaves many teams relying on controls that were not built for current proxy traffic, especially where CGNAT and NAT make IP-level decisions unreliable.

The Shortcomings of Traditional Methods

Legacy bot protection providers often combine IP reputation, network characteristics, header analysis, and JavaScript-based checks to identify proxy usage. These methods struggle against well-run residential proxies:

IP and ASN categorisation: Ages quickly as new proxy networks emerge.
Network-level checks: Well-configured proxies can work around them.
Header analysis: Proxies can alter HTTP headers to mimic legitimate traffic.
JavaScript-based detection: Struggles against headless browsers and leaves API endpoints vulnerable.

The CGNAT and NAT Challenge

A practical limit of traditional methods is their inability to distinguish legitimate traffic from proxy traffic when both originate from the same IP address. Carrier-Grade NAT (CGNAT) and Network Address Translation (NAT) make this common:

CGNAT: Used by ISPs to conserve IPv4 addresses, resulting in multiple users sharing a single public IP.
NAT: Commonly used in home and business networks, allowing multiple devices to use one public IP address.

As a result, legitimate users and residential proxy traffic can appear to come from the same IP address. IP reputation and geolocation alone cannot separate these traffic types.

This creates a difficult tradeoff:

Blocking suspicious IPs risks denying service to legitimate users.
Allowing all traffic from these IPs opens the door to potential abuse via residential proxies.

Traditional methods cannot reliably pull apart these different types of traffic, so teams either block too much legitimate traffic or allow too much proxy traffic through.

The Need for Sophisticated Network Fingerprinting

To detect and mitigate residential proxy threats while allowing legitimate traffic from shared IPs, detection needs to move beyond IP identity. Network fingerprinting addresses the limits of traditional methods:

Deep packet inspection: Analyses traffic patterns and characteristics beyond basic IP or header indicators.
Protocol behaviour analysis: Identifies subtle anomalies in how network protocols are implemented across the proxy chain.
TLS fingerprinting: Examines unique characteristics of TLS handshakes to detect proxy usage.
Timing analysis: Measures small differences in network latency that can indicate the presence of a proxy.

Used together, these techniques can detect proxy usage on a per-connection basis for both web traffic and API calls, even when traffic originates from shared IP addresses. This approach provides several advantages:

Improved accuracy: Significantly reduces false positives and negatives compared to traditional methods, including in CGNAT and NAT scenarios.
API protection: Secures API endpoints, which are often overlooked by JavaScript-based solutions.
Real-time detection: Allows for immediate action against detected proxy usage without impacting legitimate users.
Adaptability: Can be updated to detect new proxy technologies as they emerge, regardless of IP sharing.

Implementing Effective Proxy Detection

To implement proxy detection that accounts for modern network complexity, organisations should consider the following:

Deploy solutions that use network fingerprinting techniques capable of distinguishing between different types of traffic from the same IP.
Ensure protection covers both web applications and API endpoints, as both are vulnerable to proxy-based attacks.
Implement real-time mitigation capabilities to respond swiftly to detected threats without impacting legitimate users.
Regularly update and tune detection algorithms to keep pace with evolving proxy technologies and network architectures.

Together, these practices improve an organisation's ability to detect and mitigate residential proxy threats across credential stuffing, account takeover, and related activity, while keeping access available for legitimate users.

Learn more about our proxy detection solution, which uses network fingerprinting to address the challenges posed by CGNAT and NAT.

For more detail, explore our learning resources:

As proxy technologies and network architectures change, detection and mitigation need to change with them. Network fingerprinting gives organisations a more reliable way to identify residential proxy abuse without treating every shared IP as suspicious.

Quantifying The Residential Proxy Threat

2024-07-18T10:00:00+10:00

Our 2024 survey found that only 15% of Australian businesses use residential proxy detection. That leaves a measurable blind spot in many security programmes: traffic routed through real consumer connections is harder to separate from legitimate users. This article looks at why residential proxy detection is difficult and how to quantify the risk before choosing controls.

Understanding the Residential Proxy Threat Landscape

Residential proxies use IP addresses assigned to residential internet connections, so malicious traffic can look legitimate. This weakens controls built around IP reputation, GeoIP, and simple request thresholds, and creates a specific detection problem for security teams.

The effectiveness of residential proxies stems from their ability to:

Use legitimate IP addresses, often from unsuspecting users
Bypass IP-based rate limiting and traditional bot detection methods
Evade geolocation restrictions, making GeoIP filtering less reliable
Support large-scale attacks without triggering typical alarm thresholds
Mimic legitimate user behaviour, which makes detection more difficult

These capabilities make residential proxies useful infrastructure for credential stuffing, data scraping, and attempts to bypass fraud detection systems. Because the traffic is distributed across many residential connections, attacks can stay below the thresholds that conventional controls rely on.

Limitations of Conventional Security Approaches

Conventional controls have clear gaps when they are applied to residential proxy traffic:

IP-based detection misses constantly changing, legitimate-appearing IP addresses.
GeoIP filtering becomes less useful against globally distributed residential IPs.
User agent analysis struggles because proxies can mimic legitimate browsers.
Standard rate limiting falters when attacks appear to originate from many unique IPs.
Behavioural analysis based on known bot patterns may miss more careful proxy-based attacks.

These limitations point to a practical requirement: security teams need controls that assess context, not just static request attributes. Residential proxies make simple rule-based decisions less reliable, especially when attacks are distributed and deliberately low-noise.

Quantifying the Risk

To make a sensible decision about residential proxy controls, organisations need to quantify the risk. This involves:

Assessing the potential financial impact of successful attacks via residential proxies
Evaluating the likelihood of such attacks based on industry trends and organisational attractiveness to attackers
Determining the effectiveness of current security measures against this specific threat
Calculating the return on investment for implementing advanced detection and mitigation strategies

Risk quantification gives businesses a clearer basis for investing in residential proxy detection. It aligns security spending with actual threat levels and potential impacts, rather than broad concern or industry pressure alone.

Reframing Security

The challenge of residential proxy detection is less about one new control and more about how signals are combined. A useful approach includes:

Contextual Analysis: Analyse the full context of each request, not just its origin. This includes examining patterns of behaviour across multiple sessions and users.
Continuous Monitoring and Adaptation: Use real-time monitoring systems that can detect subtle patterns indicative of proxy use. These systems should continuously adapt to new attack vectors.
Risk-Based Authentication: Use dynamic authentication mechanisms that adjust based on the assessed risk of each session or transaction.
Holistic Data Analysis: Correlate data from multiple sources - including login attempts, transaction patterns, and user behaviour - to identify anomalies that may indicate proxy use.
Proactive Threat Hunting: Actively search for indicators of residential proxy use within your network and user base, rather than waiting for attacks to trigger alerts.

This approach moves beyond simple allow/block decisions and gives teams a better view of user and network behaviour.

Implementing Advanced Detection Strategies

Residential proxy threats need detection that looks beyond the source IP:

Machine Learning-Based Behavioural Analysis: Use AI and machine learning to identify patterns consistent with proxy use, even when individual actions appear legitimate.
Device Fingerprinting Beyond IP: Use advanced fingerprinting techniques that identify individual devices based on a combination of factors, making it harder for proxies to mimic legitimate users.
Network Traffic Analysis: Analyse network behaviour at a granular level to identify patterns consistent with proxy network traffic.
Adaptive Challenge Mechanisms: Deploy targeted challenges based on risk assessment, without disrupting legitimate user experiences.
Cross-Organisational Data Sharing: Participate in threat intelligence sharing networks to gain broader insights into residential proxy activities and emerging attack patterns.

When used as part of the broader security stack, these strategies improve defence against residential proxy threats.

Elevating Security Through Risk Quantification

Residential proxies are not only a technical detection problem. They change the risk model for web applications because attacker traffic can borrow the appearance of ordinary residential users. By adopting a risk quantification approach and implementing advanced detection strategies, organisations can:

Align security investments with actual threat levels
Improve detection of sophisticated, proxy-based attacks
Strengthen overall security posture against evolving threats
Make data-driven decisions about security priorities and resource allocation

Organisations that handle this well will be able to quantify their risk, adapt their security strategies, and implement intelligent detection mechanisms. The goal is practical: identify, analyse, and mitigate sophisticated threats before they cause material damage.

Effective protection starts with understanding the risk well enough to measure it.

Account Protection and User Experience in Web Applications

2024-07-17T10:00:00+10:00

Web applications face a wide range of security threats, but customer accounts are often the target. Our recent survey of Australian businesses showed a need for stronger account protection measures. Those controls can add friction for users if they are applied too broadly. This article looks at ways to balance security with user experience in web applications.

The Challenge: Compromised Credentials

Our survey found that 21% of organisations cited reputation loss as their main cybersecurity challenge. That result points back to a practical security problem: compromised credentials.

Causes of compromised logins include:

Phishing attacks
Password reuse across multiple sites
Data breaches exposing user credentials
Credential stuffing attacks
Keylogging malware

These risks make password-only authentication a weak control for customer account protection.

Moving Beyond Traditional Multi-Factor Authentication

Multi-Factor Authentication (MFA) adds a useful security layer, but it can also add friction. Our survey found that only 40% of organisations implement bot protection, which leaves a clear gap around automated attacks.

While 77% of surveyed businesses use MFA, that figure can hide other weaknesses. MFA alone doesn't protect accounts from every attack path.

Learn more about the limitations of traditional MFA

Contextual Security: A User-Focused Approach

Contextual security helps reduce that tradeoff between protection and user experience. It assesses the risk of each login attempt using factors including:

Location of the login attempt
Time of day
Device used
User behaviour patterns
IP address reputation
Network characteristics

By analysing these contextual factors, web applications can apply adaptive authentication without asking every user to complete an extra step every time.

Figure 1: Key factors considered in contextual security

Implementing Contextual Security in Web Applications

To improve account protection without adding unnecessary friction, consider these controls:

Real-time monitoring: Track user activity and detect anomalies.
Adaptive authentication: Adjust security requirements based on the risk level of each login attempt.
Behavioural analysis: Use machine learning to understand user behaviour and flag suspicious activity.
Transparent security measures: Apply checks that don't require additional user actions for low-risk scenarios.
Risk-based access controls: Apply stricter security measures for high-risk actions or sensitive data access.
Bot protection: Detect and mitigate automated attacks.
API security: Protect APIs from abuse and unauthorised access.
Residential proxy detection: Identify and mitigate threats from residential proxy networks.

For web applications, the goal is targeted control rather than blanket friction.

The Role of User Education

User education still has a place in a security strategy. Training and awareness programs can help users understand:

The importance of strong, unique passwords
How to identify phishing attempts
The risks of password reuse across multiple sites
The importance of keeping software and devices updated
How to recognise and report suspicious activities

User education works best when it supports technical controls rather than carrying the whole burden.

Addressing Mobile Application Security

Our survey indicates a potential gap in mobile security strategies. As mobile apps take on operations like banking and e-commerce, they become part of the application attack surface.

Only 30% of respondents implement Web Application and API Protection (WAAP), indicating many businesses may not be ready to protect their mobile assets. That gap leaves mobile applications exposed to attacks, including API abuse and data exfiltration.

The Threat of Residential Proxies

Our survey found that only 15% of organisations use residential proxy detection. That low adoption rate leaves a weakness in many businesses' security postures.

Residential proxies can threaten account security by:

Bypassing traditional IP-based rate limiting
Evading geolocation-based restrictions
Facilitating large-scale credential stuffing attacks
Enabling undetected data scraping

Businesses should consider security providers that can detect and mitigate residential proxy threats.

Learn more about residential proxy detection

Finding the Balance

Balancing account protection and user experience in web applications requires more than a single control. By implementing contextual security measures, organisations can:

Improve security without unnecessary impact on user experience
Adapt to threats in real-time
Reduce the risk of compromised credentials and account takeovers
Protect against threats like residential proxies and mobile application vulnerabilities

As threats change, account protection needs to change with them. Contextual security gives organisations a practical way to protect users and their reputation.

The Cost of Credential Stuffing

2024-07-17T00:00:00+10:00

In recent months, Australian businesses have faced a wave of credential stuffing attacks. These attacks do not require the affected website itself to be breached. They target customer accounts, leading to fraudulent transactions. The damage is practical as well as reputational: disputed purchases, refunds, locked accounts, and customers asking how someone else was able to use their account.

What is Credential Stuffing?

Credential stuffing occurs when attackers use login details obtained from a data breach to access accounts on other sites. Criminals test millions of credentials against a target website to identify working combinations. This attack affects users who reuse passwords across multiple services [1].

The Scale of the Problem

Tens of thousands of Australian online accounts are reported to have been accessed since late November 2023 [2]. The attacks affected major retailers and service providers, including:

The Iconic
Guzman y Gomez
Dan Murphy's
Event Cinemas
Stan

The Impact

While reusing passwords between sites has long been considered poor security practice, users still do it. Blaming the customer, as 23andMe did in its response to an attack, is not a serious account protection strategy. Over 70% of Americans believe that websites have a responsibility to prevent account takeovers via stuffing attacks. Not doing so can negatively impact a business in several ways.

Financial Impact

The cost can fall on either the affected business or the affected customer. Fraudsters made significant purchases using compromised accounts. One scammer claimed to have spent over $800 on high-end alcohol at Dan Murphy's [2]. Others bought iPhones and clothing. Either the customer will be out of pocket, or the business when the customer issues a chargeback on the purchase.

Reputation Damage

The attacks leave businesses dealing with customer complaints, refunds, and visible questions about account security. The Iconic pledged to refund affected customers [1]. Dan Murphy's confirmed that a "small number of user accounts were subject to fraudulent transactions" [3].

Customer Trust

These incidents erode customer trust. Users expect businesses to make account abuse difficult, even when the original password leak happened somewhere else. When accounts are taken over, customers question the security practices of the affected companies.

Business Response

Companies responded by:

Locking compromised accounts
Issuing refunds
Encouraging customers to change passwords
Implementing stronger security measures

Dan Murphy's advised customers to "practise good password hygiene, using a strong password and changing it periodically" [3].

Prevention Strategies

To protect against credential stuffing, businesses should:

Implement multi-factor authentication
Educate customers about password security
Monitor login behaviour on their website
Implement, and regularly update, security measures, including bot management and advanced rate limiting.

Credential stuffing is not just a password reuse problem. It is an account protection problem, and businesses that sell online need controls that make stolen credentials harder to turn into purchases.

Sources:

[^1^] ABC News: "The Iconic was hit by criminals taking money by 'credential stuffing'. How can you stay safe?" [^2^] Cyber Daily: "Guzman y Gomez, Dan Murphy's customers affected in credential stuffing campaign" [^3^] The Sydney Morning Herald: "Thousands of Australians hacked in 'credential stuffing' credit card scam"

2024 Survey Insights

2024-07-16T10:00:00+10:00

Our recent survey of Australian CISOs and CTOs looked at account protection controls, planned security measures, and how teams are responding to credential stuffing and residential proxies. Key findings:

Multi-Factor Authentication (MFA) Adoption: 76.23% of Australian businesses use MFA, showing broad adoption of a baseline account security control.
Bot Protection: Currently implemented by 39.34% of organisations, with an additional 34.65% planning to adopt it.
Bot Management Solutions: Cloudflare is the most common bot management provider in the survey, used by 48.24% of respondents.
Residential Proxy (Resip) Detection: Only 13.11% of organisations currently use this technology, although many plan to implement it to address residential proxy traffic.
Credential Stuffing Concerns: Businesses are planning measures to reduce credential stuffing risk, including bot protection, MFA, and checking credentials against known breaches.
Mobile Security Gap: Low adoption of Web Application and API Protection (WAAP) suggests gaps in mobile application security.
Executive vs. Engineer Priorities: The survey showed different cybersecurity priorities between executives and engineers.

These findings point to the need for account protection strategies that go beyond MFA and address automated traffic, breached credentials, and residential proxies.

2024 Survey Insights

2024-07-16T10:00:00+10:00

Recent customer account takeovers have put account protection back on the agenda for Australian businesses. Our 2024 survey of Australian CISOs and CTOs shows how respondents are using MFA, bot protection, WAAP and residential proxy detection to manage credential stuffing and account takeover risk.

Account Protection: Current State and Future Plans

Our survey found 76.23% of Australian businesses use Multi-Factor Authentication (MFA). MFA is widely adopted, but it is not a complete account protection strategy on its own.

39.34% of organisations currently use bot protection. That matters because credential stuffing is automated by design. Another 34.65% of businesses plan to implement bot protection in the future.

The pattern is clear: many organisations are treating MFA as a baseline and looking at additional controls around it.

Current Bot Management Solutions

The survey also asked which bot management solutions Australian businesses currently use. Cloudflare was the clear leader, with nearly half of respondents using its services.

The breakdown of bot management solutions is as follows:

Cloudflare: 48.24%
AWS WAF Bot Ruleset: 10.59%
Other solutions make up the remaining percentage

This distribution is concentrated around Cloudflare. Outside that, the remaining respondents are spread across other solutions rather than one clear alternative.

Tooling matters here. Residential proxy traffic weakens IP reputation and simple rate limits, so detection capability, request grouping and response controls matter as much as vendor name. If residential proxies continue to feature in credential stuffing tooling, this mix may shift as teams look for more advanced protection measures.

The Rising Threat of Residential Proxies

A key finding from our survey is the low adoption rate of residential proxy (resip) detection, with only 13.11% of organisations currently using this technology. Planned adoption suggests teams are starting to account for the risk, but current coverage is still low.

Resips are difficult for account security teams because malicious traffic can look like normal ISP traffic. They enable attackers to:

Bypass traditional IP-based rate limiting
Evade geolocation-based restrictions
Conduct large-scale credential stuffing attacks
Scrape sensitive data undetected

The planned adoption of resip detection points to a shift in security strategies, away from simple IP-based controls and towards more specific network signals.

Learn more about the threat of residential proxies and how to detect them

Credential Stuffing: A Persistent and Growing Concern

Credential stuffing attacks continue to be a major concern for businesses. These attacks exploit password reuse across multiple sites, allowing attackers to gain unauthorised access to user accounts.

Respondents said they plan to implement several measures to reduce credential stuffing risk:

34.65% plan to implement bot protection
32.67% intend to add multi-factor authentication
31.68% aim to check credentials against known breaches

These plans point to layered account protection rather than reliance on one control.

Mobile Applications: An Emerging Attack Surface

While mobile applications were not directly addressed in our survey, the data suggests a possible gap in mobile security strategies. The low adoption rate of Web Application and API Protection (WAAP) - implemented by only 27.87% of respondents - indicates many businesses may be underprepared to protect their mobile assets.

As mobile apps become primary interfaces for critical operations, this gap leaves businesses exposed to attacks that use the same automation and resip infrastructure seen on web login flows.

Balancing Security and User Experience

The operational problem is familiar: increase assurance without making login unusable. Key considerations for enhancing account protection while preserving usability include:

Expanding beyond MFA
Implementing bot protection
Adopting WAAP solutions
Monitoring credential leaks
Focusing on API security
Implementing residential proxy detection

Explore strategies for balancing security and user experience

Executive vs Engineer Perspectives

Our survey found differences in cybersecurity priorities between executives and engineers:

Figure 3: Comparison of cybersecurity priorities between executives and engineers

The gap matters because budget, architecture, and incident response are often owned by different teams. Account protection plans need to cover both executive risk concerns and engineering realities, including the threat from RESIPs.

Final Thoughts

Our 2024 survey results point to a simple position: MFA is widely used, but it is not the whole account protection strategy. Bot protection, breached credential checks, WAAP and residential proxy detection are still unevenly adopted. That matters because credential stuffing does not depend on one weakness; it combines reused credentials, automation, proxy networks and weak response controls.

Australian businesses do not need every control at once, but they need a layered plan that reflects how account takeover attacks are run now. For teams reviewing their controls, resip detection and mobile/API coverage are worth checking explicitly because both are easy to miss if the programme is still centred on MFA and IP reputation.

Application Security Beyond MFA

2024-07-15T10:00:00+10:00

Multi-factor authentication (MFA) remains a useful defence against account takeovers, but it is not a complete control. Attackers increasingly work around MFA with social engineering, automation, and infrastructure that makes malicious traffic look ordinary.

MFA answers one narrow question: can the user present a second factor at this point in the flow? That is valuable. It does not prove the password was safe, the session will remain safe, the device is trusted, or the person entering the code has not been manipulated. Account protection needs to cover the request path before MFA, around MFA, and after MFA.

OTP Bots Target the Human, Not the Cryptography

A Kaspersky article describes the rise of OTP bots: tools that call or message users and convince them to hand over one-time passwords. The attacker does not need to break the MFA system. They need the victim to read out a fresh code at the same moment the attacker is logging in.

The usual flow is simple. The attacker obtains a working username and password from a breach, phishing kit, or credential stuffing result. They attempt a login, which triggers an OTP. The victim receives a call or message claiming to be from the bank, retailer, courier, or support team. The story is urgent enough to make the code feel like part of protecting the account, not compromising it.

AI phone assistants such as Lucy are built for legitimate business use, but similar conversational technology lowers the effort required to run more convincing criminal call flows. The security issue is not that AI magically defeats MFA. It is that a fluent, responsive call can make social engineering less scripted and harder for a user to dismiss.

This is why "we have MFA" should not end the account protection conversation. MFA can stop many stolen-password logins, but it cannot reliably stop a user from being tricked in real time.

Residential Proxies Weaken the Surrounding Checks

Attackers also work to make the login itself look unremarkable. Residential proxies route traffic through IP addresses assigned to ordinary home or mobile internet connections. That lets malicious traffic borrow the appearance of normal customer traffic.

Traditional controls often lean too heavily on IP address, geolocation, and request volume. Residential proxy networks weaken all three. An attacker can rotate through many IPs, keep each source below a simple rate limit, and choose an exit location that roughly matches the victim's country or city. If the login looks local enough, the MFA challenge may be the only control left.

That is a poor place to put all the risk. A login with a correct password, a plausible IP address, and a successful OTP can still be an account takeover. The system needs to keep evaluating the request: device and browser signals, network fingerprint, known breached credentials, velocity across accounts, and behaviour after login.

Automation Happens Before and After MFA

MFA is usually visible at the point of login, but account takeover campaigns are broader than one prompt. Bots test credential pairs across login forms and APIs. Tools such as OpenBullet and similar automation frameworks can replay login flows at scale. Breached credential lists give attackers a cheap starting point because password reuse remains common.

Once an attacker gets through, the next actions matter. They may change the email address, add a device, disable notifications, alter delivery details, use stored payment methods, transfer value, or test what the account can access. If monitoring treats a successful MFA as the end of risk, those actions can happen inside a trusted session.

The defence needs to be layered around the actual attack path:

Check credential risk before and during login, especially known breached username and password pairs.
Use bot and browser signals to detect automation even when traffic is distributed.
Rate limit on better keys than IP alone, such as TLS or HTTP/2 fingerprints, headers, routes, ASNs, countries, and account behaviour.
Treat residential proxy evidence as a risk input, not just an allow-or-block label.
Monitor session and account changes after MFA, then challenge, hold, revoke, or review when behaviour changes.

This does not mean every login needs more friction. It means the system should have more choices than "ask for MFA" or "allow". A low-risk login from a known device can keep moving. A login using breached credentials through proxy infrastructure can be slowed, challenged, or blocked before the user receives a confusing call. A successful login followed by high-risk account changes can trigger fresh verification or session invalidation.

Controls Around MFA

Peakhour's Advanced Rate Limiting helps reduce reliance on IP address by grouping and limiting requests using signals such as HTTP/2 and TLS fingerprints, ASNs, countries, request headers, and route context. That matters when credential stuffing is spread across residential proxies.

Peakhour's Bot Management adds another layer by looking for automation, browser inconsistency, suspicious device patterns, and residential proxy use. The aim is to identify the machinery behind the attack before it becomes a clean-looking login attempt.

Peakhour's Account Protection brings those signals closer to the account decision. Breached credential checks, bot evidence, rate limits, proxy context, custom rules, and monitoring should all feed the decision to allow, challenge, rate limit, block, log, or review.

User education still has a place, especially around OTP sharing and unexpected calls. It should not be the main control. Users are asked to make security decisions at bad moments, often under pressure, with limited context. Technical controls should reduce the number of times an attacker can create that moment.

MFA Still Belongs in the Stack

The point is not to remove MFA. Strong MFA, especially phishing-resistant methods, raises the cost of account takeover and should remain part of the stack. The mistake is treating MFA as proof that the account is safe.

Account protection works better when MFA is one decision point inside a wider system. The login attempt, credential history, network path, device, session, account changes, and transaction behaviour all carry evidence. MFA is useful evidence. It is not the whole case.

How To Exclude Query String Parameters from Search Engine crawling

2024-05-21T13:00:00+10:00

Last year we wrote about the problem of excessive crawling from search engine spiders. Search engines such as Google and Bing aim to index as much content as possible. For ecommerce sites, this often means indexing pages with query string parameters used for sorting, filtering, or pagination. Those parameters help users navigate the site, but they can cause a few predictable crawler problems:

Over-Crawling: Search engines may spend too much time crawling similar pages with different parameters, wasting crawl budget.
Duplicate Content: Pages with different parameters can be treated as duplicate content, weakening SEO performance.
Server Load: Excessive crawling can increase server load, slow down your site, and affect user experience. Search engines typically account for 30-50% of page requests to an ecommerce store. Managing their crawling effectively can have a material effect on site speed and server spend.

Another common cause of over crawling is internal searches being indexed.

In our previous article we mentioned using the webmaster tools provided by Google and Microsoft to manage crawler behaviour by adding ignored parameters. Since then, both tools have been updated and no longer allow you to add parameters to ignore during a crawl.

Differences in Crawling and Indexing

Search engines maintain an 'index' of web pages. Pages in this index are what appear in search results. To maintain the index, the search engine crawls a website to 'discover' new content and keep existing entries up to date. Webmasters can control what gets indexed with tags or headers in their web pages. These include:

Canonical Tags can be used to indicate the preferred version of a page. This helps consolidate link 'juice' and tell the search engine which URL to index.
Noindex tags can be used to prevent specific pages from being indexed. This is useful for thank you pages, admin pages or any content you don't want to appear in search results.
Nofollow links can be used to indicate to a search engine not to pass on SEO value to the linked page.

However, controlling what does or does not get indexed does not prevent content from being crawled. The only way to do that is via the robots.txt file. You may be familiar with the Disallow directive in the robots.txt file, but you can also use wildcards to prevent crawling of url parameters.

An example...

Consider an ecommerce store that has a category page which can then be customised with the following parameters:

    orderBy
    colors
    brands
    page
    results

These may appear in any order, and the combinations can result in 100s or even 1000s of variations of essentially the same page. Google is fairly smart when presented with this scenario, but Bing.... Bing can crawl very aggressively and it likes to try everything. In our example above, we may want to stop crawling everything except the page number, in which case an effective way to control crawler behaviour would be:

    User-agent: *
    Disallow: /*?*orderBy=*
    Disallow: /*?*colors=*
    Disallow: /*?*brands=*
    Disallow: /*?*results=*

We can't really do this in a single Disallow because the parameters might be in any order. By including the ? in the url we're ensuring that the parameter names are only in the query string, not in the main url path. This prevents crawlers from wasting crawl budget and putting unnecessary load on server resources.

Final Thoughts

Search engines can often make up 30-50% of the overall page requests to a website. Managing their behaviour helps maximise useful crawling and minimise server utilisation. Keep an eye on your access logs for unwanted behaviour, and use robots.txt where it gives you the right level of control.

Addressing Key Cloud Security Categories

2024-05-01T10:00:00+10:00

A recent Scale Venture Partners analysis sets out emerging opportunities in cloud security after Wiz. Peakhour is a reverse proxy rather than a cloud control-plane product, but it addresses several of these categories and covers related security needs at the application edge.

Cloud Security Posture Management (CSPM)

The analysis identifies CSPM as a key category in cloud security. Peakhour is not a traditional CSPM, but it contributes to security posture management through:

Traffic Analysis: Peakhour analyses incoming traffic patterns to identify potential security risks.
Configuration Recommendations: Peakhour recommends security configuration improvements based on observed traffic patterns.

Cloud Workload Protection Platform (CWPP)

The article notes that CWPP products provide granular protection for cloud workloads. Peakhour contributes to workload protection through:

Application-Layer Filtering: Peakhour filters traffic at the application layer to protect cloud workloads.
Real-Time Threat Detection: Peakhour detects and blocks threats in real-time.

Cloud Detection & Response (CDR)

CDR focuses on detecting, investigating, and responding to incidents. Peakhour supports CDR work via:

Log Generation: Peakhour generates detailed logs of all traffic for incident investigation.
Anomaly Detection: Peakhour detects anomalous traffic patterns that indicate security incidents.
Automated Response: Peakhour responds to detected threats by blocking malicious traffic.

Cloud-Native Application Protection Platform (CNAPP)

The analysis defines CNAPP as a combination of CSPM, CWPP, and CDR. Peakhour aligns with that model through:

Integrated Security: Peakhour provides a single platform for traffic filtering, threat detection, and response.
Application-Centric Protection: Peakhour's reverse proxy design protects cloud-native applications at the application edge.

Cloud Infrastructure Entitlement Management (CIEM)

Peakhour does not directly manage cloud infrastructure entitlements, but it complements CIEM efforts through:

Access Pattern Analysis: Peakhour analyses access patterns to applications, providing insights that can inform entitlement decisions.

Non-Human Identity (NHI)

The article highlights the growing importance of managing non-human identities. Peakhour contributes to this area by:

Service-to-Service Communication Monitoring: Peakhour monitors and controls service-to-service communication.

Remediation Ops (RemOps)

RemOps focuses on managing the growing volume of security alerts. Peakhour supports RemOps through:

Alert Aggregation: Peakhour aggregates security events from traffic analysis into usable alerts.
Prioritisation: Peakhour prioritises alerts based on threat severity and potential impact.

Additional Peakhour Capabilities

Peakhour also addresses cloud security needs outside the categories covered in the Scale VP analysis:

DDoS Protection

Peakhour provides DDoS protection via:

Layer 7 Rate Limiting: Peakhour protects against application-layer DDoS attacks.
Traffic Anomaly Detection: Peakhour identifies and mitigates DDoS attacks in real-time.

Content Delivery Network (CDN)

Peakhour's delivery and cache functionality reduces cloud load and traffic bills through:

Traffic Optimisation: Peakhour reduces load on origin servers and decreases traffic bills.
Geographic Distribution: Peakhour serves content from geographically distributed nodes.

Bot Management

Peakhour manages bot traffic through:

Bot Detection: Peakhour identifies bot traffic.
Policy Control: Peakhour implements policies for managing different types of bots.
Automated Mitigation: Peakhour applies countermeasures against malicious bot activity.

Cloud Visibility

Peakhour addresses visibility gaps in modern cloud environments:

Traffic Insights: Peakhour provides detailed insights into front-end traffic patterns.
Real-Time Analytics: Peakhour delivers real-time analytics on traffic, threats, and application behaviour.

Final Thoughts

Peakhour addresses several categories identified in the Scale VP analysis of emerging cloud security opportunities. It also covers adjacent needs at the application edge, where traffic, threats, bots, delivery, and visibility meet.

See how Peakhour's Application Security Platform addresses key areas of modern cloud security. Contact our team to strengthen your cloud security posture.

Managing Breached Credential Usage

2024-03-15T00:00:00+11:00

Credential stuffing attacks remain a common way to take over accounts on applications and APIs. For DevOps, SRE, and DevSecOps teams, the problem is not just whether a password is correct. It is whether the login attempt carries signs of automation, credential reuse, or known compromise. Effective account protection needs breached credential checks alongside contextual risk analysis.

Breached Credential Databases and Risk Profiling

Modern Application Security Platforms can use breached credential intelligence containing billions of leaked username and password combinations from historical data breaches. Used at login time, this gives security teams an immediate signal that an account may be at higher risk, even before there is confirmed account takeover activity.

Enterprise Credential Intelligence

Peakhour's Application Security Platform includes Breached Credentials protection designed to work with existing authentication systems. The platform provides:

Real-Time Credential Checking: Validation against breached credential data during login attempts
API-Native Integration: Integration with authentication services and identity providers
Privacy-Preserving Verification: Hashing mechanisms that protect user privacy whilst enabling threat detection
DevSecOps Compatibility: RESTful APIs for security automation and CI/CD workflows

Building Statistical Models

To detect credential stuffing, organisations need a baseline for normal breached credential use. This typically involves:

Collecting data from API and login endpoint attempts
Aggregating data using device fingerprints
Analysing login patterns and credential use frequency
Establishing baselines for typical user behaviour

These models show how often breached credentials appear in normal login traffic, and when the pattern starts to look like automated testing rather than ordinary user behaviour.

Application Security Platform Integration

Breached credential checks are most useful when they feed into the rest of the application security stack:

Multi-Layer Defence Strategy

Edge Processing: Credential validation at the CDN edge
API Protection: Coverage for both web applications and mobile APIs
Bot Management Integration: Correlation with bot detection systems to identify automated credential testing
Rate Limiting Coordination: Rate limits adjusted by credential risk

DevSecOps Operational Excellence

Security Automation: Response workflows for high-risk credential attempts
Compliance Reporting: Audit logging and monitoring for security reviews
Threat Intelligence Feeds: Updates from breach monitoring
Custom Rule Engine: Policy configuration for organisation-specific requirements

Conclusion

Breached credential protection is one part of account takeover defence. On its own, it can show that a password has appeared in a breach. It should sit alongside broader controls such as bot management, rate limiting, API protection, and DDoS mitigation, while still giving teams a clear basis for deciding whether to block, challenge, or monitor a login attempt.

The practical goal is to make credential risk visible at the point of authentication without treating every user as suspicious. That requires breached credential checking to be part of the login flow, not a separate report reviewed after the attack has already run.

Rate Limiting for API Security

2024-01-24T13:00:00+11:00

Rate limiting prevents servers from being overwhelmed by too many requests in a short period of time. Typically, rate limiting is configured using rules made up of a filter, for example a path like /login, and a limit on the number of requests a user can make in a given time, such as 10 requests in a minute. If a user exceeds this limit, they are usually blocked for a timeout period.

But how do you identify a user? Traditionally rate limiting has used the IP address for grouping requests, assuming that requests from the same IP address will be the same user. That assumption is now weak. IP addresses are rarely static and are often shared. For example, an office network might have hundreds of individual computers in it but present a single IP address for all those computers to the internet. Mobile operators commonly use carrier-grade network address translation (CGNAT) to share the same IP across thousands of devices or users. Bot networks, seeking to avoid security controls like rate limiting, will rotate their requests through thousands of different IP addresses. This makes rate limiting based on IP addresses a poor choice from both a functional and a security perspective.

Introducing Advanced Rate Limiting

Peakhour's Advanced Rate Limiting service lets you create filters using any HTTP request characteristic, for example URI, request method, headers, cookies, country, network fingerprints and more. You can also use response headers and response codes, so a rule can count failed login attempts, repeated 404s from a scraper, or traffic that crosses an API threshold.

For counting requests you can use the following fields for grouping:

IP Address
ASN
Country Code
HTTP/2 Fingerprint
TLS Fingerprint
Any combination of Request Headers

You can use one of those fields, or a combination of them, to identify users with more control than IP address alone.

You can also separate the filter and mitigation expression. For example excessive attempts to /login can be blocked on the entire site.

This matters because rate limiting is not just a request counter. In Peakhour it sits beside bot management, WAF, DDoS protection, traffic controls, and origin shielding on the same managed edge path. That gives operators a practical way to set different thresholds for verified crawlers, suspicious automation, authenticated API clients, and normal visitors without pushing every policy change into the application. It also gives them allowed, blocked, and threshold-hit evidence to tune the rule after it is deployed, whether Peakhour is the active edge or adding controls beside an existing CDN or cloud edge.

Putting it into action

Advanced Rate Limiting can help protect applications from attacks like Layer 7 DDoS, Account Takeovers, Credential Stuffing, and more. Here are some real world examples you can configure using our dashboard and API.

Protect against general site abuse

Our example website is a medium-sized ecommerce store that has page URLs ending in /. It serves Australian clients and typically sees around 100 page requests a minute from non-search-engine traffic during peak traffic times. With that baseline, we can set up rate limiting to prevent general site abuse and protect against layer 7 DDoS attacks.

Peakhour rate limiting starts with zones. You specify your request limits in these zones.

Here we've specified a maximum of 45 requests in 1 minute. We're going to apply this limit to page loads only. Since our typical maximum for all users on this website is 100 in a minute, it seems reasonable that a real user is not going to view 40 pages in 1 minute. We could also specify a value for error responses in a minute. An error could be a 404, which a scraper might typically get when looking for removed URLs.

Now let's define our filter and our counter. For our filter we mentioned that pages end in /, so we'll use that, but exclude verified bots to make sure they're not restricted when crawling the site. A verified bot is a crawler like Google or Bing, that Peakhour has verified as legitimate by using reverse DNS to confirm they are who they say they are.

Attackers, scrapers, and others looking to abuse a site will launch an attack using a particular piece of software. That piece of software will have a TLS fingerprint (like JA3) that remains the same, even as the attacker rotates their user-agent, IP address, and other characteristics, so we'll use the TLS fingerprint as our request counter.

Rate Limit authenticated API Users

It is common for APIs to require an Authorization header as part of the request to authenticate access. By grouping requests on the value of this header, we can rate limit a specific API client even if it uses multiple applications, or if its credentials are stolen.

Protecting from Account Takeovers

Account Takeover attacks have been in the news recently, with several high-profile websites being victims. Credential Stuffing and Brute Force attacks rely on attempting lots of logins to identify valid credentials. Along with lots of attempts come lots of failures. Attackers will rely on software like openbullet to carry out their attacks, using proxy networks to constantly rotate IP addresses and defeat traditional rate limiting.

The program the attacker is using will present a consistent TLS fingerprint. We can make a special rule for our login form that tracks failed login attempts by TLS Fingerprint, effectively tracking the attacker as they rotate IP address.

If the attack is low and slow, we can track failed attempts over a longer timeframe by using the response from the server when adding to our counting zone.

Final Thoughts

Advanced rate limiting is a practical response to the limits of IP-based controls. IP address rotation is the standard amongst attackers and scrapers, rendering the traditional approach obsolete. Useful protection now needs to identify the actor behind the requests, protect the origin before expensive application work is triggered, and give teams enough evidence to adjust the policy without guesswork. Counting requests against a combination of network fingerprints, request fields, response signals, and bot context is how you stop abuse from scrapers, SEO spiders, and layer 7 attackers without treating every visitor the same.

The Iconic is the latest Account Takeover victim in the news

2024-01-15T13:00:00+11:00

Major Australian fashion ecommerce website theiconic.com.au recently announced it would refund victims of an account takeover attack. The attack allowed fraudsters to order items using stored credit cards in the victims' accounts and have them sent to locations in Victoria.

The fraud caused reputational damage to The Iconic, with users taking to social media to complain about both the fraud and the difficulty of contacting support to report it.

The Iconic deserves credit for issuing refunds to affected users. That stands in stark contrast to the response to a similar recent attack at 23andme.com. While 23andme victims didn't suffer any monetary loss, the website's response was to change its terms and conditions and blame the victims for reusing passwords across sites. That same password reuse is what allowed users at The Iconic to be defrauded.

EDIT: Since writing this article major websites, danmurphys.com.au, binge.com.au and guzmanygomez.com have all been affected by similar credential stuffing attacks.

So why and how are these attacks carried out, and what can you do about it?

Why are Account Takeover attacks carried out?

Financial gain remains a primary motivator. Once they gain control of an account, attackers can make unauthorised purchases (as in the case of The Iconic), transfer funds, or access credit card details. eCommerce platforms, financial services, and any site with stored payment information are particularly vulnerable. Bypassing fraud controls is another major motivator. Many eCommerce stores will trust orders from an existing account with a history, allowing fraudsters to order goods with stolen cards.

Access to sensitive information is another goal. Personal data, confidential business information, or intellectual property can be exploited for various illegal purposes, including identity theft, selling data on the dark web (23andMe), or corporate espionage.

ATO attacks can also enable further malicious activity. Compromised accounts can be used to distribute malware, launch further attacks, or perpetrate scams. This can damage the reputation of the affected website, erode user trust, and lead to significant financial and legal repercussions.

How are Account Takeover attacks carried out?

Common techniques used to compromise user accounts on websites include:

Phishing: Phishing involves tricking users into revealing their login credentials. Attackers send emails or messages resembling legitimate communications from trusted entities, directing users to fraudulent websites where their details are captured.

Credential Stuffing: This method involves using previously breached username and password pairs to gain access to accounts on different websites. Because many users reuse passwords across multiple platforms, attackers can successfully breach accounts by trying these known combinations. Credential Stuffing is the type of attack used on both The Iconic and 23andMe.

Brute Force Attacks: Attackers use automated software to generate and try a vast number of username and password combinations until they find the right one to gain access.

Social Engineering: Beyond technical methods, fraudsters often use social engineering tactics to manipulate individuals into revealing their credentials. This can be through phone calls, social media interactions, or other personal contact methods.

What can users do about it?

Users can reduce the risk of their accounts being taken over by:

Using a password manager to use strong, different passwords on different sites.
Checking their commonly used emails on have I been pwned and, if listed, making sure the exposed passwords are updated.
Making sure MFA (Multi Factor Authentication) is enabled if available on a website.
Being alert to phishing attempts. Never follow links/call numbers in emails. Go to a site directly to login/look up phone numbers. If you receive a phone call asking for personal/login information always hang up and call back on an official company number to be sure you're talking to a legitimate company representative.

What can websites do about it?

Quite a bit. Websites can minimise the risk by:

Enforcing strong passwords.
Providing MFA options on log in forms to make account takeover more difficult.
Checking logins against Have I been Pwned to alert users that their account might be compromised.
Locking accounts after 3 or more failed attempts for a set amount of time.
Emailing account holders when changes to an account happen, eg changes to email or delivery address.
Preventing automated abuse of login forms, we'll go into more detail in the next section.
Monitoring login attempts for suspicious activity, ie unusual amounts of attempts/failures and odd locations.

Preventing automated log in attempts

Credential stuffing and brute force account takeover attacks rely on trying many combinations of usernames/passwords to find valid logins. They rely on automated tools like openbullet to carry out these attacks. There are many techniques that can mitigate attacks of increasing sophistication. Some can be implemented on your server if you have the expertise, or at your CDN/WAF provider if you have one.

Block attempts to log in over HTTP 1.1. This rule relies on the fact that most attackers will be using scripting/programming languages for their automation. All modern browsers will use HTTP 2 or higher, while scripts will use 1.1 by default.
Block attempts with no/incorrect referrer header. To log in you have to visit a login page and fill out a form, automated scripts bypass the login page and POST straight to the login handler, more often than not the referring login page is missing in the request.
Use Bot Management to detect automated attempts at logging in. Bot management services can use sophisticated techniques like network and browser fingerprinting and behavioural analysis, ie mouse movement/form access/speed, to determine whether the login attempt is human or a bot.
Use Advanced Rate Limiting to limit log in attempts from a class of device. No bot management solution is foolproof, sophisticated attackers will use full browsers and rotate their IP address using residential proxies to get past protections. Traditional IP address based rate limiting is useless against these sorts of attacks. Advanced rate limiting can count attempts by the connecting program type to defeat attacks and generate alerts when an attack is happening.
Use residential proxy detection to flag logins as a fraud signal.

Conclusion

Unfortunately 23andMe used the tactic of blaming the victims for reusing passwords. While offering MFA, they didn't enforce it, and clearly didn't enforce strong passwords. Further, while they had a major security vendor in place, that vendor was either ineffective, or not utilised properly. All up 14k accounts were compromised, and 7 million other accounts accessed via a sharing feature. That level of activity should have been caught much earlier unless the attacker was extremely sophisticated and patient, carrying out their attack over a long period of time. That amount of effort belies the claim by 23andme that the "the information that was potentially accessed cannot be used for any harm". Haven't they heard of Bond villains making genetic weapons...

The Iconic have the same security vendor as 23andme and don't offer MFA. Their automated prevention is weak (no bot protection and only IP based rate limiting which allowed for 300 attempts), which allowed the attacks to happen. Desperate users were notified of changes to their accounts, but couldn't get in touch with support to prevent the attackers using their stored credit cards. To their credit, The Iconic is refunding clients.

While no countermeasure is perfect at preventing Account Takeovers, the potential loss of reputation and damage to clients makes it imperative that website owners take practical steps to prevent them. While users also bear responsibility for securing their accounts, websites that hold sensitive information need to take every possible step to protect themselves and their users, not just wash their hands and blame the victims.

HTTP Security Headers

2023-11-28T14:00:00+11:00

Traditionally, web security has focused on the server side: protecting the application itself from attack. That work is necessary, but it often leaves the client side under-specified. Client-side attacks move the exposure point into the user's browser, where the business impact can be serious.

Magecart attacks are a clear example. Attackers inject skimming scripts into websites to steal sensitive customer information, such as credit card details, directly from the user's browser. Session hijacking and Cross-Site Scripting (XSS) attacks also exploit browser vulnerabilities, leading to unauthorised access and data breaches. These attacks don't just risk user data; they can erode trust, damage reputations, and result in significant financial and legal repercussions for businesses.

HTTP security headers are practical controls for these types of attacks. Properly implemented, they instruct browsers on how to handle website content and interactions safely.

Key HTTP Security Headers

Content-Security-Policy (CSP)

Purpose: CSP prevents Cross-Site Scripting (XSS) attacks by specifying which sources browsers should allow when loading scripts, images, and other resources. It can also prevent MageCart-style attacks by restricting the host names that an injected script can communicate with.

Content-Security-Policy: script-src 'self' https://apis.google.com;

This example allows scripts to load only from the site's own domain ('self') and https://apis.google.com.

X-Frame-Options

Purpose: This header protects against clickjacking attacks by controlling whether a browser allows a page to be rendered in a <frame>, <iframe>, <embed>, or <object>.

X-Frame-Options: DENY

This setting prevents any domain from framing the content. Another option is SAMEORIGIN, which only allows framing by the same site.

X-Content-Type-Options

Purpose: This header prevents MIME-sniffing, where a browser might incorrectly interpret the content type of a resource, leading to security vulnerabilities.

X-Content-Type-Options: nosniff

This instructs the browser to follow the content type declared in the HTTP headers.

X-XSS-Protection

Purpose: This enables the browser's inbuilt XSS protection features. However, this header is largely deprecated in favour of CSP.

X-XSS-Protection: 1; mode=block

This configuration enables the protection and tells the browser to block the page if an XSS attack is detected.

Strict-Transport-Security (HSTS)

Purpose: HSTS forces the browser to use HTTPS over HTTP, ensuring encrypted communication and protecting against man-in-the-middle attacks. Alternatively, you can automatically redirect all requests to HTTPS on your web server or at your EDGE provider. For example, Peakhour allows you to set up EDGE redirects to force all traffic to HTTPS.

Strict-Transport-Security: max-age=31536000; includeSubDomains

This example tells the browser to use HTTPS for all subdomains for one year.

Conclusion

Implementing the correct HTTP security headers is a straightforward way to improve web application security. These headers form part of the first line of defence against many common security vulnerabilities. As threats evolve, keeping security headers current and properly configured helps safeguard your users and your brand.

RFC 9460

2023-11-16T00:00:00+11:00

RFC 9460 introduces two DNS record types: "SVCB" (Service Binding) and "HTTPS". They let browsers learn more connection details during DNS lookup, before redirects and TLS negotiation add extra steps. The result is cleaner connection setup, with practical improvements in speed, security, and efficiency.

Understanding the Current Process

Traditionally, when a browser connects to a website, it follows a sequence:

Browser requests site via HTTP.
Server redirects request to HTTPS.
Browser receives ALPN (Application-Layer Protocol Negotiation) during the HTTPS handshake.

The model is secure, but it is not optimal. It involves multiple round trips, which affects Time to First Byte (TTFB) and the overall user experience. Load balancing and failover are also less direct than they could be. RFC 9460 changes this by allowing DNS to provide the necessary connection details earlier. That reduces the steps involved in establishing a secure connection, lowering TTFB.

The Impact of SVCB and HTTPS Records

SVCB and HTTPS records move useful connection hints into DNS. They speed up the time-to-first-packet by incorporating the Alt-Svc HTTP header and ALPN TLS extension into DNS, which shortens connection setup. These records also enable redirection at the zone apex, a task not possible with CNAMEs. They simplify DNS load distribution and failover, making web services more resilient. They also remove the need for HSTS preloading and support Encrypted Client Hello (ECH), formerly ESNI, for better privacy.

Adoption and Industry Response

Adoption started before the RFC was finalised. Firefox has been conducting HTTPS lookups since May 2020, limited to DNS over HTTPS (DoH). Apple's iOS, Safari, and macOS have followed suit since September 2020. Chrome introduced partial support in December 2020 and has recently enabled ECH by default. Various DNS service providers have also started supporting HTTPS and SVCB records.

As reported on Netmeister, adoption is still early but not insignificant. As of October 2023, about 10 million domains have implemented an HTTPS record for their 'www' service names, roughly 4.4% of domains. Around 9.1 million domains, or about 4.0%, use the record on their bare second-level domain name. Among the top 1 million domains, approximately 22.5K (25.5%) use HTTPS records for 'www' service names, and nearly 24K (25.6%) use them on bare domains.

What the Records Look Like

A typical SVCB record might look like this:

_example.com. 7200 IN SVCB 1 svc4.example.net. (alpn="h2,h3" port="8004")

This record indicates that the service at _example.com can be accessed at svc4.example.net using either HTTP/2 or HTTP/3 on port 8004.

An HTTPS record could be:

example.com. 3600 IN HTTPS 0 svc.example.net.

This record suggests that example.com should be accessed securely through svc.example.net.

Apex Domains and the Importance of SVCB/HTTPS Records

One long-running DNS limitation is the inability to use CNAME records at the apex (root level) of a domain due to conflicts with other necessary records like NS and SOA. RFC 9460's SVCB/HTTPS records address this by enabling apex domain aliasing without those conflicts. This matters for efficient content delivery networks (CDNs) and load balancing strategies.

These records enhance capability

1. Load Balancing:

Consider a website that needs to distribute traffic across multiple servers. SVCB records can indicate different server endpoints with varying priorities.

example.com. IN SVCB 10 server1.example.com. (alpn="h2,h3")
example.com. IN SVCB 20 server2.example.com. (alpn="h2")

In this example, server1.example.com is the preferred endpoint (lower priority number), offering both HTTP/2 and HTTP/3 protocols. If it's unavailable, traffic automatically shifts to server2.example.com.

2. Failover Mechanism:

For a service that requires high availability, SVCB records can express failover directly:

critical-service.example.com. IN SVCB 1 primary-service.example.com. (alpn="h2,h3")
critical-service.example.com. IN SVCB 2 backup-service.example.com. (alpn="h2")

Here, primary-service.example.com is the primary endpoint. If it fails, the system automatically falls back to backup-service.example.com.

3. Apex Domain Usage:

A practical advantage of SVCB/HTTPS records is their ability to handle apex domains, where CNAME records are not feasible. This is important for root domain aliasing to different service providers.

example.com. IN HTTPS 0 cdn-provider.example.net.

This record indicates that the apex domain example.com is to be served through cdn-provider.example.net, overcoming traditional DNS limitations.

4. Encrypted ClientHello Support:

Future enhancements of SVCB could include keys for Encrypted ClientHello, which improves privacy and security during the initial TLS handshake.

secure.example.com. IN SVCB 1 tls-service.example.net. (ech="base64-encoded-key")

This record can be used to initiate a TLS connection with tls-service.example.net using the provided Encrypted ClientHello key.

5. Directing Traffic to Specific Protocols:

For services that need to direct clients to newer or more efficient protocols, SVCB records can specify the exact protocols to use.

api.example.com. IN SVCB 1 api-server.example.com. (alpn="h3")

Clients that understand HTTP/3 can connect directly using this protocol, bypassing the usual HTTP/1.1 or HTTP/2 protocols.

The Long Wait

HTTPS has been around for a while, so RFC 9460 raises an obvious question: why did this take so long? Apex records have had their share of problems, including not being able to use CNAMEs and having to resort to custom records like ALIAS or Cloudflare's 'cname flattening'.

It is a fair question. We've had some bizarre records hanging around for ages along with a wide range of solutions to the "CNAME at the zone apex" problem.

Credit to the creators of RFC 9460 for getting this through and obtaining browser support: - B. Schwartz from Meta Platforms, Inc. - M. Bishop from Akamai Technologies - E. Nygren from Akamai Technologies

Final Thoughts

RFC 9460 gives DNS a more useful role in HTTPS connection setup. SVCB and HTTPS records let operators publish endpoint, protocol, failover, and privacy information before the browser starts negotiating the connection. That gives service providers more precise control over how clients reach web services, with practical benefits for performance, reliability, and security.

Dive into CVSS Scores

2023-11-10T00:00:00+11:00

Understanding CVSS through Atlassian Confluence Vulnerabilities

The Common Vulnerability Scoring System (CVSS) gives security teams a shared way to rate the severity of software vulnerabilities. It does not predict risk on its own; it describes the characteristics of a specific security flaw. CVSS uses three metric groups: Base, Temporal, and Environmental. The result is a score from 0 to 10, represented by a vector string that records the details behind the score.

Base Metrics describe the inherent aspects of a vulnerability, including how it can be exploited and its potential system impact.
Temporal Metrics change over time, reflecting current exploitability and available mitigations.
Environmental Metrics account for the specific environment where the vulnerability exists, tailoring the score to the affected organisation.

The National Vulnerability Database (NVD) utilises CVSS to assign base scores and provides tools for calculating Temporal and Environmental scores.

Atlassian Confluence Vulnerability Analysis

Two Atlassian Confluence vulnerabilities show why the vector matters as much as the headline score:

CVE-2023-22515 is a critical flaw with a base score of 10.0. It is exploitable remotely, with low complexity, no privilege requirements, and no need for user interaction. The attack vector is network-based, so exposure is not limited to local access. Its broad scope and impact across confidentiality, integrity, and availability make it a vulnerability that needs immediate attention.

CVE-2023-22518 shares many similarities with CVE-2023-22515, including a critical base score of 10.0. It can also be exploited remotely without privileges or user interaction, and with low complexity. Its impact on the system's confidentiality, integrity, and availability is high, allowing attackers to gain complete control and shut down the affected resources.

Both CVE-2023-22515 and CVE-2023-22518 are critical vulnerabilities that demand urgent remediation. Understanding their CVSS vectors helps prioritise the security response and the mitigations needed.

CVE-2023-22515 carries a CVSS score of 10 because it is remotely exploitable, easy to execute, and does not require privileges or user interaction.

CVSS Vector for CVE-2023-22515

Base Score: 10.0 (Critical)
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This vector indicates:

Attack Vector (AV): Network (N) - The vulnerability is remotely exploitable.
Attack Complexity (AC): Low (L) - It is easy to exploit without major obstacles.
Privileges Required (PR): None (N) - No special access is needed.
User Interaction (UI): None (N) - It can be exploited without user involvement.
Scope (S): Changed (C) - The impact extends beyond the initial target.
Confidentiality, Integrity, Availability (C/I/A): High (H) - There is a complete loss of confidentiality, integrity, and availability.

Atlassian's high CVSS score for CVE-2023-22515 reflects its critical nature and the need for immediate action.

CVE-2023-22518 has the same CVSS score of 10, with similar impact across confidentiality, integrity, and availability.

CVSS Vector for CVE-2023-22518

Base Score: 10.0 (Critical)
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This vector means:

Attack Vector (AV): Network (N) - Exploitable remotely.
Attack Complexity (AC): Low (L) - Easy to exploit with minimal barriers.
Privileges Required (PR): None (N) - No user privileges required.
User Interaction (UI): None (N) - No need for user action.
Scope (S): Changed (C) - Broad impact beyond the initial system.
Confidentiality, Integrity, Availability (C/I/A): High (H) - Complete compromise of the system's security.

Understanding the CVSS scores for these vulnerabilities helps teams prioritise their security response. For a full breakdown and history of CVSS, see Wikipedia. More detailed information on CVSS can also be found in FIRST's official CVSS documentation.