Forwarded

TL;DR: Standardized header that preserves original client information (IP, protocol, host) when requests pass through proxies. Modern replacement for X-Forwarded-* headers.

What is Forwarded?

The Forwarded header is the standardized way (RFC 7239) to preserve original request context across proxies:

• client address (for=)
• proxy identifier (by=)
• original host (host=)
• original scheme (proto=)

It unifies older de-facto headers like X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host.

Syntax

Forwarded: by=<identifier>; for=<identifier>; host=<host>; proto=<http|https>
```text

Multiple proxy hops append values as a comma-separated list:

```http
Forwarded: for=203.0.113.10;proto=https, for=198.51.100.7;by=203.0.113.5

Example

Forwarded: for=192.0.2.60; proto=https; by=203.0.113.43
```javascript

## Parsing and Trust

Like other forwarding headers, this value can be spoofed if accepted from untrusted clients.

Use it safely:

- trust only known reverse proxies/load balancers
- ignore forwarding headers from direct internet traffic
- prefer framework support for trusted proxy chains

## Implementation

```javascript
const forwarded = req.headers.forwarded
// Parse: for=192.0.2.60; proto=https

Forwarded vs X-Forwarded-*

Forwarded is standards-based, but many stacks still rely on X-Forwarded headers. In production, it is common to accept both while migrating.

Common Mistakes

• Treating the leftmost for= as trusted without proxy validation
• Assuming every proxy emits all parameters (for, by, host, proto)
• Ignoring IPv6 and quoted identifier formats during parsing

Related Headers

• X-Forwarded-For
• X-Forwarded-Proto
• Via

Forwarded vs X-Forwarded-* in Production

The Forwarded header is the IETF standard (RFC 7239) that replaces the older X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host headers with a single structured format. Despite being standardized since 2014, adoption has been slow because the X-Forwarded headers are deeply embedded in load balancers, CDNs, and application frameworks.

In practice, most infrastructure still emits X-Forwarded headers. AWS ALB, GCP Load Balancer, Cloudflare, and nginx all default to X-Forwarded-For rather than Forwarded. Some systems emit both. When migrating, it is safest to accept both formats and prefer Forwarded when present.

The Forwarded header has a richer syntax that handles edge cases the X-Forwarded headers cannot. IPv6 addresses must be quoted in Forwarded (e.g., for="[2001:db8::1]"), whereas X-Forwarded-For has no standard quoting rules. The by parameter identifies the proxy that added the entry, which is useful for tracing the request path through a multi-hop proxy chain.

Trust boundaries apply equally to both header families. Neither Forwarded nor X-Forwarded-For can be trusted if they arrive from untrusted sources. The only reliable defense is to configure your edge proxy to strip and rewrite these headers on incoming requests, ensuring that only your own infrastructure can set them. Any value that arrives from the public internet before reaching your proxy should be treated as potentially spoofed.