Compare the HTTP Forwarded header defined by RFC 7239 with X-Forwarded-For and X-Forwarded-Proto, and explain how a service behind several proxies should determine the real client IP.

## What the fields carry When a request passes through reverse proxies, the origin's socket only sees the last proxy. The lost facts — original client IP, original scheme, original Host — are re-added as headers. **De-facto set:** - `X-Forwarded-For: 203.0.113.9, 198.51.100.4` — client first, then each proxy appends the peer address it saw. - `X-Forwarded-Proto: https` — the scheme the *client* used, which matters because TLS usually terminates at the edge and the app sees plain HTTP. - `X-Forwarded-Host`, `X-Forwarded-Port` — the original authority. **Standard (RFC 7239):** one `Forwarded` field, a comma-separated list of hop elements, each a semicolon-separated set of parameters: `Forwarded: for=192.0.2.43;proto=https;host=api.example.com, for="[2001:db8::1]:4711";by=203.0.113.7` Parameters: `for` (client of that hop), `by` (the interface that received it), `proto`, `host`. Values may be quoted, may include ports, IPv6 must be bracketed and quoted, and **obfuscated identifiers** like `for=_hidden` are allowed for privacy — a real advantage over the X- form, which can only carry raw addresses. ## Why both exist `X-Forwarded-For` predates any standard and became universal, so RFC 7239 could not simply rename it — the whole cautionary tale RFC 6648 warns about. Practically: emit and accept `X-Forwarded-*` because that is what CDNs, ALBs and nginx produce, and accept `Forwarded` too if anything upstream emits it. Do not merge blindly; if both are present, decide by policy which one your trusted edge sets, and ignore the other. ## Determining the client IP safely The critical property: **proxies append, they do not sanitise**. If a client sends `X-Forwarded-For: 1.2.3.4` and your CDN adds the true peer, the origin receives `1.2.3.4, <real client>`. Taking the first element hands the attacker complete control of "the client IP". The correct algorithm: 1. Know your topology: exactly how many proxies you control sit in front of the app (call it N), or the CIDR set of their addresses. 2. Parse the list left to right in append order; the rightmost entry was added by the closest proxy. 3. Walk from the **right**, discarding entries that came from trusted proxies. The first untrusted address you reach is the client. 4. Equivalently, with a fixed chain of N trusted hops, take the (N+1)th element from the right. 5. If the list is shorter than expected, do not fall back to the leftmost value — treat it as untrusted and fall back to the socket peer address. Extra care: strip whitespace, handle IPv6 with brackets and ports, cap the list length (a client can send hundreds of entries and blow up your parser or your header budget), and reject malformed entries rather than coercing them. ## What depends on getting it right - **Rate limiting and abuse controls** keyed on a spoofable IP are no controls at all; an attacker rotates the header and each request looks like a new client. - **IP allowlists** protecting admin endpoints can be bypassed outright. - **Geo-blocking and fraud signals** become attacker-chosen. - **Audit logs** record whatever the attacker wanted them to record. - **`X-Forwarded-Proto`** drives redirect and cookie decisions: an app that sees plain HTTP behind a TLS-terminating edge will build `http://` absolute URLs and may refuse to set `Secure` cookies unless it honours this header. Trusting it from an untrusted source, conversely, lets a client claim `https` and defeat force-HTTPS logic. ## Configuration in practice - Frameworks expose it: a trusted-proxy list or hop count. Set it explicitly; defaults are usually "trust nothing" (safe but wrong behind a load balancer) or "trust everything" (convenient and exploitable). - The **edge you control should overwrite, not append**, the client-supplied value for its own hop where possible — many CDNs offer a "true client IP" header they set authoritatively for exactly this reason. - Anything not from a trusted hop should be treated as user input: length-capped, format-validated, and never interpolated into logs or SQL unchecked. - Same discipline for `X-Forwarded-Host`: honouring an attacker-supplied host is how password-reset links get poisoned. ## Summary comparison `Forwarded` is the standard, single, extensible, privacy-aware field; `X-Forwarded-*` is the split, ubiquitous, less rigorous one. Neither is authenticated. The security property does not come from the header choice — it comes from knowing which hops you trust and counting from the right end.