Forwarded is the standardized version of the X-Forwarded headers, defined in RFC 7239. It puts the client address, proxy address, original host and protocol in one field so values stay paired. Neither it nor X-Forwarded-For can be trusted unless the proxies that set them are trusted.
What RFC 7239 defines
The Forwarded header lets proxies disclose information that is otherwise lost when a request passes through them, such as the client's IP address. It is optional. The parameters are:
- for: the client or node that made the request to the proxy.
- by: the proxy interface where the request arrived.
- host: the original Host header value the proxy received.
- proto: the protocol used, typically http or https.
The RFC example shows a client at 192.0.2.43 reaching an origin through two proxies, ending in Forwarded: for=192.0.2.43, for=198.51.100.17;by=203.0.113.60;proto=http;host=example.com.
How it differs from X-Forwarded-For
X-Forwarded-For is widely used but not standardized. It carries only addresses. Companion headers X-Forwarded-Proto and X-Forwarded-Host carry the rest, as separate fields. With Forwarded, one field holds everything, so a server can tell which values belong together, provided the proxies are trusted.
Converting between them works for simple cases. IPv6 addresses must be quoted and bracketed in Forwarded. Conversion can fail when both X-Forwarded-For and X-Forwarded-By are present because their relative order is unknown.
In practice, many proxies and frameworks still emit X-Forwarded headers by default. nginx's realip module reads X-Real-IP, X-Forwarded-For or the PROXY protocol, and Caddy and Apache set X-Forwarded values themselves. If your chain has mixed products, pick one convention and strip the other at the edge.
The security consideration that matters
The RFC says plainly that the header cannot be fully trusted. Any node on the path, including the client, can alter it. Whitelisting proxies helps but has limits, and an attacker on the network can modify unsecured traffic.
That is the same rule as for X-Forwarded-For: the application must read only entries added by proxies it trusts, from the right, and ignore anything a client could have supplied. The nginx real_ip post and the Caddy trusted_proxies post show how.
Privacy and leaks
Client IP addresses are privacy sensitive, as they can identify a user, their network operator and an approximate location. The RFC advises that servers and intermediaries should not copy the header into responses, and that hosts should restrict TRACE, which could echo it back. It can also expose internal network structure, so egress proxies should strip sensitive entries. The Apache TRACE setting is covered in Apache ServerTokens and TraceEnable.
Practical rules
- Decide which header your chain uses and document it.
- At the first proxy, discard any such header from the client, or overwrite it.
- In the application, trust only the number of hops you operate.
- Do not use these values for authorization, only for logging and soft limits, unless the chain is locked down.
- Do not echo them in responses or error pages.
Where Safeguard fits
Safeguard does not parse your headers. It scans the libraries that do, through dependency scanning and SBOMs, and can gate pull requests with policies. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
Is Forwarded more trustworthy than X-Forwarded-For?
Not by itself. It is standardized and keeps values paired, but any node including the client can set it, so trust depends on the proxies.
Sources
Last reviewed: 19 October 2026.
