Forwarded, origin IP, and privacy across proxy chains

The for, by, host, and proto parameters can reveal client address, proxy interface, original host, and connection scheme.

First identify which component actually consumes for, by, host, or proto and for what decision. If the application needs only the original scheme for redirects, do not forward the full client address. A correlation ID plus an edge record is often enough for investigations. Document chain direction, IPv6 formatting, and handling of unknown or obfuscated identifiers.

An external client can send the header itself. The edge proxy should remove untrusted values or create a new verifiable chain.

At the external edge, remove Forwarded and equivalent X-Forwarded-* values supplied by untrusted clients, then create a new value. Internally, allow only known proxy hops over authenticated connections to append. Applications should trust a bounded hop count and parse the chain by a documented rule; accepting the first address blindly enables audit and access-control spoofing.

Send only parameters required for a defined function. The standard supports obfuscated identifiers for tracing without exposing internal structure.

If an exact IP is unnecessary after the operational window, replace it with a stable pseudonymous identifier protected by a separate key or aggregate to a network prefix where purpose permits. Pseudonymization does not necessarily remove personal-data obligations, so basis and safeguards still matter. Keep addresses out of client responses, telemetry tags, and error messages.

If IP addresses enter logs, document purpose, access scope, and retention. Export them only under an established basis.

For each IP copy, define storage, roles, search, export, and automated deletion. A full address in a short-lived security log and aggregate statistics may need different periods. Reassess purpose and basis before a new use such as marketing analytics. Verify current legal and contractual requirements before enabling the feature.