Peakhour.IO - Edge Security

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.

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.