Host Header Injection
detect, understand, remediate
Host header injection exploits applications that trust the HTTP Host header for URL generation, enabling password reset poisoning, cache poisoning, and server-side request routing manipulation.
No credit card required. Free plan available forever.
What is host header injection?
Host header injection is a web security vulnerability that occurs when a server implicitly trusts the HTTP Host header value supplied by the client and uses it to generate URLs, redirect links, or other security-sensitive output. Because the Host header is entirely controlled by the requester, an attacker can supply an arbitrary value that the application then embeds into password reset emails, cached pages, or redirect destinations. This class of vulnerability is tracked as CWE-644 and frequently leads to account takeover, phishing, or web cache poisoning.
The most common exploitation scenario involves password reset flows. When a user requests a password reset, the application generates a unique token and constructs a reset link using the Host header to determine the domain. An attacker who intercepts or manipulates this header can cause the reset link to point to a domain they control, capturing the token when the victim clicks the link. This enables full account takeover without needing to exploit any authentication weakness directly.
Host header injection can also be chained with cache poisoning to serve malicious content to other users. If a reverse proxy or CDN caches responses keyed on the URL but not the Host header, an attacker can inject a poisoned Host value that gets cached and served to legitimate visitors. This makes the vulnerability especially dangerous in environments with shared caching infrastructure, as a single poisoned request can affect thousands of users. Related vectors include open redirects that become exploitable when combined with a manipulated Host header.
How it works
Intercept request
The attacker intercepts an HTTP request to the target application using a proxy tool and identifies endpoints where the Host header influences server behaviour.
Modify Host header value
The attacker replaces the legitimate Host header with a domain they control, such as attacker.com, or appends additional headers like X-Forwarded-Host.
Server uses injected host
The application uses the attacker-controlled Host value to construct URLs in password reset emails, redirect responses, canonical links, or cached content.
Password reset or cache poisoning
The victim receives a password reset link pointing to the attacker's domain, leaking the reset token, or the poisoned response is cached and served to other users.
Common causes
Trusting Host header for URL generation
Applications that read the Host header at runtime to construct absolute URLs for links, redirects, or API responses without validating against an allow-list of expected hostnames.
Password reset links built from Host header
Password reset mechanisms that use the Host header value to determine the domain portion of the reset URL, allowing attackers to redirect reset tokens to malicious domains.
Web cache keying on Host header
Caching layers that key responses on the URL path but not the Host header, enabling attackers to inject poisoned content that gets cached and served to legitimate users.
Virtual host routing without validation
Servers that route requests to different applications based on the Host header without verifying that the supplied value matches a configured virtual host, allowing unintended routing behaviour.
How to detect it
Automated detection
- SecPortal's external scanning automatically tests Host header manipulation on discovered endpoints and detects reflected values in responses and redirect locations
- Password reset flow analysis identifies whether reset links incorporate the Host header value, flagging potential token theft vectors
- Cache behaviour testing detects scenarios where injected Host header values persist in cached responses served to other users
Manual testing
- Submit requests with a modified Host header and inspect the response body, Location headers, and email content for the injected value
- Trigger password reset flows while supplying a controlled Host header and verify whether the reset email contains the attacker's domain
- Test X-Forwarded-Host, X-Host, X-Forwarded-Server, and other override headers to identify alternative injection points
How to fix it
Whitelist allowed Host values
Configure your web server and application to only accept requests with Host header values that match a predefined list of expected domains. Reject or redirect any request with an unrecognised Host value.
Use server-configured base URLs
Never derive the application's base URL from the Host header at runtime. Instead, store the canonical base URL in a server-side configuration file or environment variable and use that for all URL generation.
Ignore X-Forwarded-Host from untrusted sources
Only honour the X-Forwarded-Host header when it originates from a trusted reverse proxy. Configure your application to strip or ignore forwarded headers from external requests.
Use absolute URLs in emails
Construct all URLs in transactional emails (password resets, verification links, notifications) using a hardcoded, server-configured domain rather than any value derived from the incoming request.
Configure cache keys to include Host
Ensure that any caching layer (CDN, reverse proxy, application cache) includes the Host header in its cache key to prevent cross-host cache poisoning attacks.
Compliance impact
Related vulnerabilities
Check for host header injection
SecPortal tests for host header reflection, password reset poisoning, and X-Forwarded-Host manipulation. Start free.
No credit card required. Free plan available forever.