Category: Attack Techniques
Host Header Injection
Also known as: HTTP Host Header Attack, Host Header Poisoning
Simply put
Host Header Injection is an attack where a malicious actor manipulates the HTTP Host header sent in a web request to exploit how a server or application processes that value. Because many web applications trust the Host header to construct URLs, route requests, or generate links, an attacker can abuse this trust to redirect users, poison caches, or trigger unintended server-side actions. The vulnerability typically arises from misconfiguration or flawed business logic rather than a flaw in the HTTP protocol itself.
Formal definition
Host Header Injection occurs when a web application uses the value of the HTTP Host header in security-sensitive operations without adequate validation or allowlisting. Because the Host header is fully attacker-controlled in a direct request, an application that reflects this value into redirect URLs, password reset links, internal routing logic, or cache keys may be vulnerable to a range of attack classes. These include web cache poisoning (where a poisoned cache entry is served to other users), password reset poisoning (where the reset link is constructed using the attacker-supplied host, directing victims to an attacker-controlled domain), and server-side request forgery (where internal routing decisions are influenced by the injected value). Initial testing involves substituting an arbitrary domain value in the Host header and observing whether the application reflects or acts upon it. Mitigation typically involves validating the Host header against a strict allowlist of permitted server names, as implemented at the application or middleware configuration level.
Why it matters
Host Header Injection is significant because the HTTP Host header is attacker-controlled in any direct request, yet many web applications treat it as a trusted, server-side value. Applications that use this header to construct URLs, generate links, or make routing decisions introduce a category of vulnerabilities that can affect users who never interact directly with a malicious actor. This indirect harm, where a poisoned cache entry or a crafted password reset link reaches innocent users, makes the attack class particularly dangerous relative to its low exploitation complexity.
Who it's relevant to
Web Application Developers
Developers who write code that reads the Host header to construct URLs, redirect targets, or email content are directly responsible for introducing or preventing this vulnerability. Safe patterns involve retrieving the server's canonical hostname from a trusted configuration source rather than from the incoming request header.
Security Engineers and Penetration Testers
Testers should include Host header manipulation in their standard input validation test cases. As OWASP notes, initial testing is straightforward: substituting an attacker-controlled domain in the Host header and observing application behavior. Testers should also check for reflection in password reset flows, redirect responses, and cache behavior, since the impact varies significantly by context.
Platform and Middleware Administrators
Server and middleware administrators play a key role in mitigation. Implementing an allowlist of permitted Host values at the web server, load balancer, or application framework level can prevent malicious values from reaching application logic. This is the approach recommended by IBM for products such as Decision Center and Rule Execution Server.
CDN and Caching Infrastructure Teams
Teams responsible for caching layers must understand how Host header values factor into cache key construction. If an application is vulnerable to web cache poisoning via a manipulated Host header, a single attacker request may result in a poisoned response being served to many legitimate users, amplifying the impact well beyond a single victim.
Inside Host Header Injection
Host Header
An HTTP/1.1 required request header that specifies the domain name and optional port of the server the client intends to reach, used by web servers and applications to route requests and construct URLs.
Attacker-Controlled Input
The core risk element: the Host header value is supplied by the client and may be manipulated to contain an arbitrary domain or value, which the server application may then trust and use without validation.
Password Reset Link Poisoning
A common exploitation pattern where an injected Host header causes the application to generate a password reset URL pointing to an attacker-controlled domain, delivered to a victim user.
Cache Poisoning via Host Header
An attack variant where a malicious Host header value is reflected into a cached response, causing subsequent users served from that cache to receive attacker-influenced content.
Server-Side Request Forgery (SSRF) via Host Header
An exploitation path where the injected Host header influences backend routing or service-to-service requests, causing the server to issue requests to unintended internal or external destinations.
Absolute URL Overriding
An HTTP feature where providing an absolute URL in the request line may cause some servers to use that URL's host rather than the Host header, creating an alternative injection surface.
X-Forwarded-Host and Related Headers
Proxy-injected or client-supplied headers such as X-Forwarded-Host, X-Host, and X-Original-Host that applications may trust as overrides for the Host header, expanding the attack surface beyond the Host header itself.
Virtual Host Routing
The server-side mechanism that uses the Host header to determine which application or site to serve when multiple are hosted on the same IP address, making Host header integrity critical to correct routing.
Allowlist-Based Host Validation
The primary defensive control, in which the application compares the incoming Host header against a predefined list of acceptable values and rejects or normalizes requests that do not match.
Common questions
Answers to the questions practitioners most commonly ask about Host Header Injection.
Does HTTPS protect against Host header injection attacks?
No. HTTPS encrypts the transport layer but does not validate the semantic correctness or trustworthiness of HTTP headers, including the Host header. An attacker can supply a manipulated Host header value over an HTTPS connection just as easily as over HTTP. The protection HTTPS provides is against network-level interception, not against application-level header manipulation.
If my application does not explicitly use the Host header in its code, is it still vulnerable?
Potentially yes. Frameworks, libraries, and middleware components often consume the Host header implicitly when generating URLs for password reset links, redirects, canonical URLs, or email content. An application may be vulnerable through these indirect uses even if the developer never references the Host header directly in application code. Reviewing framework behavior and third-party component behavior is necessary, not just reviewing custom application code.
How should an application validate the Host header to prevent injection?
The recommended approach is to maintain an explicit allowlist of trusted hostnames and virtual host values, then validate the incoming Host header value against that list on every request. Requests with Host header values not present in the allowlist should be rejected or redirected to a safe default. Allowlist validation is preferred over blocklist or pattern-matching approaches, which are more prone to bypass.
Where is the most reliable place to enforce Host header validation, at the application layer or the infrastructure layer?
Enforcement at both layers is advisable, and the infrastructure layer typically provides the more reliable boundary. Web servers, reverse proxies, and load balancers such as nginx or Apache can be configured to reject or rewrite requests with unexpected Host header values before they reach application code. Application-layer validation provides defense in depth but should not be the sole control, particularly in environments where the application may be accessed through multiple network paths.
How can Host header injection be detected during security testing?
Testing typically involves supplying modified Host header values in requests and observing whether those values are reflected in responses, used in generated links, or influence application behavior such as redirects or password reset URL generation. Common test cases include supplying an attacker-controlled domain, adding an X-Forwarded-Host header with a different value, and using Host header values with port manipulation. Both manual testing and automated scanning tools can assist, though automated tools may miss cases where the injected value only appears in out-of-band outputs such as emails. Scope boundaries mean that testing must cover not just direct responses but also any email or asynchronous output the application generates.
Are there categories of Host header injection impact that static analysis tools typically cannot detect?
Yes. Static analysis tools can identify locations in code where the Host header value is read and used, but they typically cannot determine whether that usage is safe or exploitable without runtime context. Static tools generally cannot evaluate whether allowlist validation is correctly enforced at the infrastructure layer, whether a generated password reset link will actually reach an attacker-controlled host at runtime, or whether the vulnerability is exploitable given specific deployment topology. Runtime testing and infrastructure review are necessary to assess actual exploitability and impact beyond what static analysis can surface.
Common misconceptions
HTTPS fully prevents Host Header Injection because the connection is encrypted and the server validates the certificate.
TLS encryption protects the Host header from interception in transit, but it does not prevent a client from sending a manipulated Host header value to the server. The server-side application must still validate the header independently of the TLS layer.
Host Header Injection is only exploitable if the attacker can intercept or modify the victim's request in transit.
Many exploitation scenarios, such as password reset link poisoning, require only that the attacker send their own crafted request with a manipulated Host header. The victim does not need to be on-path; the attacker induces the server to generate a poisoned response or link that is then delivered to the victim through normal application flows.
Validating the Host header in application code is redundant if a reverse proxy or load balancer is in front of the application.
Proxy configurations vary and may forward, rewrite, or selectively pass Host and related headers in inconsistent ways. Additionally, headers such as X-Forwarded-Host may bypass proxy-level controls and still reach application code. Defense in depth requires validation at the application layer as well.
Best practices
Maintain and enforce a strict server-side allowlist of permitted Host header values, rejecting any request whose Host header does not match an expected value for the application.
Avoid using the Host header or related headers such as X-Forwarded-Host to dynamically construct absolute URLs in security-sensitive operations, including password reset links, email confirmation URLs, and OAuth redirect URIs. Use a configured base URL defined in server-side settings instead.
Explicitly configure the web server or framework to reject or normalize requests containing unexpected Host values before they reach application logic, and disable or restrict processing of override headers such as X-Forwarded-Host unless they are required and come from trusted infrastructure.
Include Host Header Injection test cases in application security testing, covering not only the Host header itself but also X-Forwarded-Host, X-Host, X-Original-Host, and absolute URL request lines, and verify that injected values do not appear in responses, generated links, or cache entries.
Treat any component in the request processing pipeline, including caches, that reflects or stores the Host header value as a potential injection point, and validate header integrity at each layer rather than assuming upstream components have sanitized the value.
When operating behind a reverse proxy or CDN, explicitly document and test which headers the proxy forwards, rewrites, or strips, and verify that the trust model between proxy and application does not allow client-supplied headers to override authoritative routing or URL construction values.