Cybersecurity glossary
What is X-Forwarded-Host?
Learn what the X-Forwarded-Host HTTP header does, how reverse proxies preserve the original Host for backends, spoofing risks without trusted proxy lists, and safe patterns for multi-tenant routing.
Definition
X-Forwarded-Host is a de-facto standard HTTP request header that carries the Host header value the client originally sent to an edge proxy, allowing backends behind TLS terminators and load balancers to perform virtual-host routing, generate correct absolute URLs, and enforce tenant isolation when the direct connection Host names the internal service instead of the public hostname.
Why X-Forwarded-Host matters
Modern deployments rarely expose application servers directly on public hostnames. Proxies terminate TLS, balance traffic, and speak to backends using internal names. X-Forwarded-Host bridges that gap so origins still know which site the user intended.
That convenience becomes a liability when applications trust host values from untrusted clients—enabling cache poisoning, open redirects, password reset hijacks, and cross-tenant data leaks.
How X-Forwarded-Host works behind proxies
The edge receives the client's Host header, may rewrite Host for upstream routing, and sets X-Forwarded-Host so the origin can recover the public hostname for routing and link generation.
Client sends Host: www.example.com
The browser or API client names the public virtual host on the request to the edge.
Proxy terminates TLS
The load balancer or ingress accepts the public connection and inspects the original Host.
Edge forwards with metadata
The proxy may set Host to an internal name and add X-Forwarded-Host with the client value.
Origin resolves the tenant
The application reads the forwarded host—only if the peer is trusted—to pick site config and canonical URLs.
Response uses correct hostname
Redirects, cookies, and absolute links reflect the public host the user expects.
Spoofing risks and mitigations
| Misuse | Impact | Mitigation |
|---|---|---|
| Trusting client-supplied X-Forwarded-Host | Forged host in redirects, emails, and password-reset links | Accept only from trusted proxy IPs; strip inbound values at the edge |
| Host reflected in cacheable HTML | Web cache poisoning across virtual hosts on shared CDNs | Include host variance in cache keys or disable shared caching on host-sensitive routes |
| Tenant routing from unvalidated host | Cross-tenant data exposure when attackers pick arbitrary hostnames | Allowlist known public hostnames; reject unknown forwarded hosts |
| Open redirect via Location built from host | Phishing using your domain's reputation | Validate redirect targets against a fixed hostname allowlist |
| Mixing Host and X-Forwarded-Host inconsistently | Split-brain routing between middleware and app code | Document one authoritative source per deployment layer |
Safe configuration patterns
Trusted proxy list
Only honor X-Forwarded-Host when the connection comes from known CDN, ingress, or balancer CIDR ranges.
Strip at the edge
Remove client-sent X-Forwarded-Host before the proxy appends the value it observed.
Public hostname allowlist
Map forwarded hosts to tenant config; reject anything not registered for the deployment.
Framework settings
Enable USE_X_FORWARDED_HOST (Django) or trust proxy host options only with matching ingress trust.
Cache key awareness
Ensure CDNs vary or partition by Host when responses differ per virtual host.
Canonical URL helpers
Centralize absolute URL builders that read trusted forwarded scheme and host together.
Security checklist
- Maintain a trusted proxy list; ignore X-Forwarded-Host from direct internet clients.
- Strip or overwrite inbound X-Forwarded-Host at the edge—never pass through unvalidated client values.
- Allowlist public hostnames your application serves; return 400 for unknown forwarded hosts.
- Never build redirect Location headers solely from untrusted host metadata.
- Include Host or X-Forwarded-Host in CDN cache keys when responses vary by virtual host.
- Align framework forwarded-host settings with the actual number and identity of proxy hops.
- Log both connection Host and forwarded host during migrations to catch misconfiguration early.
- Test host-header spoofing in staging without going through the trusted proxy path.
Limits and pitfalls
X-Forwarded-Host is not signed or encrypted independently of TLS to the edge. Compromise or misconfiguration at the proxy layer still propagates bad host metadata downstream.
Some platforms set only Host internally and omit X-Forwarded-Host entirely. Applications that assume the header always exists may fall back incorrectly. Standardize behavior across environments and document which header is authoritative for each code path.
The practical takeaway
X-Forwarded-Host lets backends see the public hostname behind reverse proxies, but only trusted edges should set it and only allowlisted applications should act on it.
Combine a trusted proxy list, hostname allowlists, and careful cache keying—treating unvalidated host input as a first-class injection surface, not harmless metadata.
Related security terms
Virtual Host
Hostname-based routing that often depends on the forwarded Host at the origin.
Reverse Proxy
Infrastructure that terminates TLS and may rewrite or supplement Host headers.
X-Forwarded-Proto
Companion header recording the original scheme for absolute URL generation.
Web Cache Poisoning
Shared-cache attacks where unkeyed Host-related headers change stored responses.
Frequently asked questions
What is X-Forwarded-Host in simple terms?
When a proxy connects to your app, the TCP Host header might say internal.example.svc. X-Forwarded-Host preserves the public hostname the user typed—www.example.com—so the app can route tenants and build correct links.
Can attackers spoof X-Forwarded-Host?
Yes, if your application accepts the header from any client. Only trust X-Forwarded-Host when the immediate TCP peer is on your trusted proxy list and the edge overwrites or validates inbound values.
When should applications use X-Forwarded-Host instead of Host?
Use it when the direct Host names an internal service but public routing, canonical URLs, or tenant resolution require the original client-facing hostname. Many frameworks expose this via USE_X_FORWARDED_HOST or equivalent settings.
How does X-Forwarded-Host relate to web cache poisoning?
If a CDN cache key ignores Host or X-Forwarded-Host but the origin response changes by hostname, an attacker can seed a poisoned page for one host that later serves to visitors of another.
What is the difference between X-Forwarded-Host and Host?
Host is the hostname on the direct HTTP connection. X-Forwarded-Host is metadata added by a proxy describing what the client originally requested. They differ whenever the edge rewrites Host for upstream routing.
How do I configure trusted proxies for host headers?
Allowlist proxy IP ranges, enable framework forwarded-host support, and ensure the edge strips client-supplied X-Forwarded-Host before setting its own value. Never reflect unvalidated host values into redirects or HTML.
References
Explore authoritative guidance and frameworks related to x-forwarded-host.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.