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.
