Cybersecurity glossary
What is Host Header Injection?
Learn what Host header injection is, how poisoned Host values break password resets and caches, how it differs from CRLF header injection, and how to validate absolute URLs safely.
Definition
Host Header Injection is a vulnerability in which an application trusts the HTTP Host header (or spoofable equivalents such as X-Forwarded-Host) to build links, reset URLs, cache keys, or security decisions—allowing attackers to poison those values and redirect users or corrupt application behavior.
Why Host header injection matters
Frameworks often expose helpers like “current request URL.” Those helpers frequently read the Host header. When password resets, invites, or OAuth callbacks are built that way, Host Header Injection turns a routing field into an attacker-controlled domain inside trusted email.
Caches and multi-tenant routers that key on Host can also serve the wrong content—or store poisoned entries—when validation is missing.
How Host header injection works
App trusts request host metadata
Code reads Host or X-Forwarded-Host to build absolute links or cache keys.
Attacker sends a poisoned Host
A request to the real site carries Host: attacker.example (sometimes with bypasses).
Server embeds the value
Emails, redirects, or cached pages include the attacker domain.
Victim follows the trusted link
Tokens or sessions leak to the attacker-controlled host.
Frequent exploitation paths
Password reset poisoning
Reset links in email point to the attacker, capturing the token.
Cache key confusion
Shared caches store responses under attacker-influenced Host keys.
Absolute URL generation
Sitemaps, webhooks, and PDF reports emit wrong origins.
Forwarded header trust
X-Forwarded-Host / Forwarded accepted from the public internet.
Prevention that works
| Control | Notes |
|---|---|
| Canonical domain config | Build absolute URLs from server config, not request Host |
| Strict host allowlist | If dynamic hosts are required, allowlist exact tenant domains |
| Overwrite at the edge | Proxies must set forwarded headers; strip client-supplied ones |
| Reject unknown Host | Web servers should serve only recognized virtual hosts |
| Separate cache keys carefully | Do not key caches on unvalidated host metadata |
| Test reset and invite flows | Verify emails always contain the expected production domain |
- Search code for URL generation that reads Host or forwarded-host headers.
- Configure a canonical public base URL for emails and callbacks.
- Allowlist virtual hosts at the reverse proxy and application layers.
- Ensure the edge overwrites X-Forwarded-* and ignores client values.
- Test password-reset with a poisoned Host and inspect the emailed link.
- Review cache configuration for Host-dependent keys.
- Document multi-tenant host rules explicitly.
- Treat successful reset-link poisoning as critical.
The practical takeaway
Host header injection is misplaced trust in client-controlled host metadata. Generate absolute URLs from configuration, allowlist real hosts, and never let public clients dictate X-Forwarded-Host.
If a password-reset email can contain an unexpected domain, fix URL generation before anything else.
Related security terms
CRLF Injection
Newline attacks that can sometimes be combined with header manipulation.
HTTP Header Injection
Forging additional headers via CR/LF rather than poisoning Host trust.
Cache Poisoning
Poisoned Host values frequently contribute to cache key confusion.
Open Redirect
Password-reset and link-generation bugs often produce open redirects.
Frequently asked questions
What is Host header injection in simple terms?
The app uses the Host header from the request to build links like password-reset URLs. An attacker sends a fake Host so those links point to an attacker domain.
Is this the same as CRLF header injection?
No. CRLF injection inserts new header lines with newline characters. Host header injection abuses the application’s trust in an already-present Host (or forwarded-host) value.
What are classic impacts?
Poisoned password-reset links, SSRF-like routing in misconfigured proxies, web cache poisoning, and corrupted absolute URLs in emails or sitemaps.
Why do X-Forwarded-Host headers matter?
Apps behind proxies sometimes prefer X-Forwarded-Host over Host. If that header is attacker-controlled at the edge, it becomes an injection point.
How do you prevent it?
Ignore client-supplied hosts for URL generation. Use a configured canonical domain allowlist, and only trust forwarded headers from known proxies that overwrite them.
Can a WAF see this?
Unusual Host values can be detected, but the reliable fix is server-side canonical URL configuration—not filtering alone.
Does HTTPS alone stop Host header attacks?
No. TLS authenticates the server certificate to the client; it does not stop the application from trusting a malicious Host string in application logic.
References
Explore authoritative guidance and frameworks related to host header injection.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.