Client address attribution
Work out who is really behind a request that arrived through a proxy or a CDN.
Why this needs setting up #
When a request arrives through a load balancer or a CDN, the address on the socket is the balancer's, and the address anyone actually connected from is written into a header that anyone can set. Detection that groups by client address — brute force from one address, credential stuffing from one address — is only as good as that attribution.
This page says which proxies you trust. Resolution happens as telemetry is accepted, and changes take effect within about half a minute.
How resolution works #
Resolution walks back through the proxy chain and stops at the first address that is not one you have declared trusted. That address is the client.
- The socket peer is not trusted — it is the client, and anything it wrote in a header is treated as its own claim rather than as fact.
- The socket peer is trusted — the forwarding headers are read and walked right to left until an untrusted address is found.
- A CDN preset is enabled and the peer is in it — the address the CDN reports is used directly.
An address the chain cannot be read past — an obfuscated identifier or a malformed value — ends the walk rather than being skipped. Stepping over a hop you cannot read is how a client address ends up being one the client chose.
How it was resolved is recorded
Every resolved request carries the method used, so you can tell an address that came from the socket, from a forwarded header, from the CDN preset, or from a value the instrumentation reported and could not be verified. That last one is worth looking at: it means the address was taken on trust.
What you can set #
- Trust private networks — on by default. Trusts loopback, private, link-local and unique-local ranges, which covers a load balancer inside your own estate.
- Trusted proxies — the addresses or ranges of specific proxies and egress gateways.
- Cloudflare edge — enables the CDN preset, trusting the published edge ranges and reading the address the CDN reports.
- Your own prefixes — the ingress ranges your organisation publishes, which are then treated as part of your own address space.
The CDN preset is maintained against the ranges its provider publishes, so turning it on does not mean maintaining a list yourself. Re-check it when you change your edge provider.
List the proxies, not the servers
Trusting a range that includes machines a client could connect to directly lets those clients set the address header themselves. Trust the load balancer and the CDN, and keep the application tier out of the trusted list.
Turning it off #
Turning off private-network trust leaves only the proxies you named. That is the right setting when your application tier is reachable from the internet, because a direct connection from a private-looking address then resolves to that address rather than to a header it chose.
Checking it #
Once it is set, App and API protection reports the share of requests where a client address was resolved, which is the number to watch. A sudden drop usually means a new proxy appeared that is neither trusted nor resolvable, and every request through it will resolve to the proxy's own address.
Set this before you turn on the rules that group by address. Detection built on attribution you have not configured will fire on your own load balancer, which is a loud and confusing first day.
Limits #
- Settings hold up to 512 proxies and prefixes.
- Changes are applied within about 30 seconds.
Onward #
Attribution feeds App and API protection, and the rules that group by address are in Detection rules.