Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Forwarded client IP: trust a hop, not a request header

Last updated: 1 Oct 20266 min read
tutorial
AdvancedBy AITrove Editorial

A forwarding header can carry a client address through HTTP proxies. A direct client can also send that same header unless the edge removes or replaces it. If an application accepts the leftmost address from any incoming request, an attacker can spoof identity for rate limits, allowlists, and audit records. The trustworthy input is the immediate peer and a configured chain of proxies that the service is allowed to trust.

Operational decision

A receipt gateway uses client IP for abuse controls. Map the public edge, internal proxy, and application peer addresses, then configure the application to accept forwarded information only from the exact proxy networks it controls. At the first trusted ingress, discard an untrusted client's supplied forwarding header before writing the verified address; downstream proxies may append according to a documented chain policy. Test a direct synthetic request with a forged internal address and confirm it cannot bypass the limiter. Test through the real edge and confirm the audit record contains both the verified client address and the proxy peer. A private network alone is not enough if another tenant or workload can connect to the application port. Review proxy network changes as a security change, and keep the raw header out of authorization decisions when the chain cannot be established.

Output
Receipt client-address contract
Public client header: untrusted input
First trusted edge: replace untrusted forwarding fields
Application peer: must match approved proxy network
Accepted client address: derived only through that chain
Audit: retain verified client plus immediate peer

Cost and verification

Trusted proxy lists require upkeep as gateways move, and extra audit fields increase log volume. If the list is too narrow, legitimate users collapse into the edge address and rate limits become unfair; if it is too broad, spoofed addresses become accepted. Measure direct-to-origin attempts, requests rejected for an invalid chain, rate-limit distribution, and mismatches between edge and application logs. A correct address is useful evidence, but it is not authentication for the customer account.

Common Mistakes

  • Do not trust a client-supplied forwarding header on a direct connection.
  • Do not use an IP address as a substitute for account authentication.
  • Do not trust an entire private address range when only named proxies should connect.

Connected lessons

Practice and check

devops
operations
Storage details