Overview

X-Forwarded-Host (XFH) is the de facto header a proxy uses to pass the client's original Host value to the backend. It corresponds to the Forwarded standard's `host` parameter.

When a reverse proxy re-requests the backend it often rewrites Host to an internal address (`localhost:3000`, etc.); the original public domain is preserved in this header.

Details

Backend applications need the public domain to build absolute URLs (redirect Location, email links, sitemaps, canonical URLs). If the proxy rewrites Host to an internal address, the backend can't know the original domain, so it uses the `www.example.com` carried in XFH.

This value shares the exact security risk of the Host header: it is client-controllable, so if an app builds absolute URLs from XFH, a 'Host/Forwarded header injection' can plant an attacker domain into password-reset links, enabling phishing and cache poisoning.

The safe principle mirrors XFF: let only trust-boundary proxies set this header, and have the backend validate it against an allowlist of expected hosts before using it to build absolute URLs. Passing through multiple proxies can append several comma-separated values, so be careful how you interpret the first one.

Syntax

X-Forwarded-Host: <host>[:<port>]

e.g. X-Forwarded-Host: www.example.com

Notes

• Absolute URLs built from XFH carry the same risk as Host header injection — always validate against an allowlist of expected domains.
• If the proxy rewrites Host to an internal address but doesn't set XFH, the backend's redirects and canonical URLs can leak the internal address.
• Treat XFH arriving from outside the trust boundary as client-forged, and reset/sanitize it at the outermost proxy.

Related headers

Specification