Host header injection: how it works, how testers prove it, how to fix it

Host header injection is a bug in which an application trusts the HTTP Host header, or a header that overrides it, to build links, route requests or make security decisions. The client controls both. PortSwigger says the main cause is the flawed assumption that the header is not user controllable.

Only test systems you own or have written authorization to test. Every example here uses a fictional app on example.com.

What is host header injection?#

The Host header names the domain the client wants to reach. It is mandatory as of HTTP/1.1. It lets one IP address serve many sites, through virtual hosting or through intermediaries such as load balancers, reverse proxies and CDNs. PortSwigger calls an attack "Host header injection" when a payload goes straight into that header.

The bug has three common forms. The application writes the header into a link, such as a password reset URL. A cache stores a response that contains the header value. Or a front-end server uses the header to choose a back end, so a crafted value reaches a host that was never meant to be public.

Do not mix it up with HTTP header injection. That bug, also called CRLF injection, inserts line breaks into a header value so the attacker can add headers or split a response. Scanner reports often use the two names loosely. Host header injection has a different cause and a different fix.

Applications trust it wherever they need their own address. Testers check these places first.

• Password reset and email verification links built from the request host.
• Absolute URLs in redirects, canonical tags, Open Graph tags and script imports.
• Cache keys and cached responses (see web cache poisoning).
• Virtual host routing and internal-only sites on the same server.
• Allowlist checks that read X-Forwarded-Host when Host is missing.
• Redirect targets that feed an open redirect.

OWASP's WSTG adds a point about overrides: if the server rejects a bad Host, the tester can keep the real Host and put the test domain in X-Forwarded-Host, where the value may appear in page output.

How the attack works: password reset poisoning#

The attacker asks for a password reset for a victim's account with a Host header the attacker controls. The application builds the reset link from that header, so the victim receives a real email whose link points to the attacker's domain. If the victim clicks, the reset token goes to the attacker.

POST /account/forgot-password HTTP/1.1
Host: canary.example.net
Content-Type: application/x-www-form-urlencoded

email=tester%40example.com

Reset your password:
https://canary.example.net/account/reset?token=<redacted>

OWASP's description of this case says the victim's click sends the secret token to the attacker, who can then reset the password. The password reset vulnerabilities page covers the rest of that flow.

The main variants#

Testers vary two things: where the value goes, and which header carries it. The table lists the cases in PortSwigger's and OWASP's guidance.

Port injection is a variation testers also try: a value after the colon in Host that the application copies into URLs. Check that case when the application writes the port into links.

Real incidents and CVEs#

Reset poisoning keeps appearing in shipped software. Each entry is from the National Vulnerability Database (NVD), checked 9 November 2026.

The Litestar entry shows why a host allowlist is not finished until it covers the override headers too. The braindump and phpBB entries show the same flaw in the default way each framework builds absolute URLs.

How penetration testers detect and prove it#

OWASP's method starts simple: supply another domain in the Host header and see how the server processes it. The result depends on how the server treats the value, so the tester records what changed.

1. Send a baseline request, then repeat it with a canary domain in Host. Record the status code, redirects and any place the canary appears in the body or headers.
2. If the server rejects the changed Host, keep the real Host and set X-Forwarded-Host to the canary. Try X-Host and Forwarded too.
3. Test a request with no Host and only an override header, a duplicate Host header, and an absolute URL in the request line. These show how a proxy and the application disagree.
4. For each place the canary appears, say what the application does with it: a link, a redirect, a script import or a routing choice.
5. For reset poisoning, use a test-owned account and a mailbox you control. Read the email and record the link host.
6. For cache effects, add a unique cache buster and confirm with a second client, as in the cache poisoning method.
7. Run controls. Send the same request with the real host and confirm the link is correct. Send a reset for a nonexistent account and compare the response, because a different message is a user enumeration finding of its own.

Evidence is labeled "Observed" for the requests, responses and email, and "Browser-observed" when a poisoned page runs in Chromium. A reflected canary in a comment or unused tag is an observation, not a high finding. A reset email with an attacker-chosen host is a finding. Never trigger a reset for a real user.

How to prevent host header injection#

PortSwigger's prevention tips fit one rule set. Avoid the header in server-side code. Set the public domain in configuration for absolute URLs. Validate the host against an allowlist. Disable override headers. Restrict routing to named hosts. Keep internal-only applications off public servers.

The same idea in code: the base URL is a constant, and the request host is checked, not trusted.

const BASE_URL = process.env.PUBLIC_BASE_URL; // https://notes.example.com
function resetLink(token) {
  return `${BASE_URL}/account/reset?token=${encodeURIComponent(token)}`;
}

The table lists the per-stack setting, with what each project's documentation says.

Python (Django). List exact names. Avoid '*' unless a first middleware validates the host.

ALLOWED_HOSTS = ["notes.example.com", "www.notes.example.com"]
# USE_X_FORWARDED_HOST stays False unless a trusted proxy sets it

Ruby (Rails).

Rails.application.config.hosts << "notes.example.com"

PHP (Laravel).

->withMiddleware(function (Middleware $middleware): void {
    $middleware->trustHosts(at: ['^notes\.example\.com$'], subdomains: false);
})

Node.js (Express). Trust only the proxy hop you run, and do not read the hostname for links.

app.set("trust proxy", 1); // one trusted proxy that overwrites X-Forwarded-*

Java (Spring Boot). Choose the strategy that matches the proxy, and keep Tomcat's trusted proxy range narrow. The documentation says not to trust all proxies in production.

server.forward-headers-strategy=NATIVE

C# (ASP.NET Core).

{ "AllowedHosts": "notes.example.com" }

Go. The standard library does not check hosts for you. Reject anything outside a fixed set.

var allowed = map[string]bool{"notes.example.com": true}

func hostGuard(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		h, _, err := net.SplitHostPort(r.Host)
		if err != nil {
			h = r.Host
		}
		if !allowed[strings.ToLower(h)] {
			http.Error(w, "bad host", http.StatusBadRequest)
			return
		}
		next.ServeHTTP(w, r)
	})
}

nginx. A catch-all server stops unknown names from reaching an app.

server {
    listen 80 default_server;
    server_name _;
    return 444;
}

Apache.

ServerName notes.example.com
UseCanonicalName On

How should proxies and CDNs handle X-Forwarded-Host?#

The edge should remove any client-supplied X-Forwarded-Host and set its own, or the application should ignore the header. Express documents the risk: with trust proxy on, req.hostname is taken from that header, which the client or proxy can set, so the last trusted proxy must overwrite it.

Check three things in the proxy layer. First, whether the proxy forwards the original Host or rewrites it. Second, whether it passes a client's X-Forwarded-* headers through. Third, whether the application validates the final host after the proxy has run, as the Litestar fix did. If a cache sits in the path, remember that the cache key usually contains Host and may not contain an override header.

Testing checklist#

• Is every place that builds an absolute URL listed (email, redirects, tags, imports)?
• Does the changed Host header alter any of them?
• Do X-Forwarded-Host, X-Host and Forwarded alter them?
• Does a request with no Host and only an override pass validation?
• Does the reset email use a fixed domain for a test-owned account?
• Does the server have a catch-all default that rejects unknown hosts?
• Does a cached page contain the canary after a buster test?
• Do controls with the real host stay correct?

When to get a professional test#

Host handling spans the application, the web server, the proxy and the CDN, so one layer's test can miss another layer's trust. A tester needs written scope and a test-owned account and mailbox to prove reset poisoning safely. Excession Labs checks host handling as part of a web application penetration test, with the evidence standard described above.