An application builds absolute URLs — password-reset links, redirects, canonical tags — from the HTTP Host header of the incoming request. What can go wrong, and how would you make host handling safe at the edge and in the application?

## The premise: Host is user input A request header is whatever the client typed. `Host: shop.example.com` is not verified by anything — TLS validates the *server's* identity to the client, not the client's claim about which site it wants. The same is true, doubly, of `X-Forwarded-Host`, `X-Forwarded-Server`, and the standard `Forwarded` header: those are hints written by whoever spoke last, and a direct client can write them itself. Frameworks make it easy to forget this. Helpers that produce an absolute URL — `url_for(..., _external=True)`, `UriComponentsBuilder.fromHttpRequest(...)`, `request.build_absolute_uri()`, `$_SERVER['HTTP_HOST']` — read the request host by default. That is convenient and usually correct, until the value is attacker-chosen. ## Exploit 1: poisoned password-reset links The highest-impact case, because it turns a header into account takeover: 1. The origin has a catch-all vhost: any Host reaches the app. 2. The attacker POSTs to `/password/reset` with `[email protected]` and `Host: attacker.example`. 3. The app creates a one-time token and renders the email body with an absolute link derived from the request host: `https://attacker.example/reset?token=…`. 4. The victim receives a genuine email from the genuine sender and clicks. 5. The attacker's server logs the token; the attacker resets the password. Nothing in the flow is a phishing email — the mail is authentic, which is why the click-through rate is high. ## Exploit 2: cache poisoning If a shared cache (CDN, reverse-proxy cache) keys on path but the response reflects the request host into the body — a canonical `<link>`, a script `src` on an assets host, an absolute redirect — an attacker can request the page with `Host: attacker.example` (or, more commonly, `X-Forwarded-Host: attacker.example`, since that is not usually part of the cache key), get it stored, and have subsequent legitimate visitors served a page that loads the attacker's script. The unkeyed-input problem is general: any request field that changes the response but is not in the cache key is a poisoning vector. ## Exploit 3: routing past the edge When an edge terminates TLS and routes to backends by Host, and an internal service is reachable at the same IP, sending an internal hostname in Host can reach services that were never meant to be public. The SNI can be a legitimate public name; the Host does the routing. Related: SSRF payloads that reach an internal address but set Host to a public vhost name. ## Layered defence **At the edge / web server** - Define an explicit **default server** for each listener that does *not* serve the app. In nginx, a `default_server` block returning `444` (close without response) or `421`; in Apache, a first vhost that returns 421/404. This removes the catch-all that all three exploits rely on. - Match hostnames explicitly (`server_name shop.example.com www.shop.example.com;`) rather than with broad wildcards. - **Strip** inbound `X-Forwarded-Host` / `Forwarded` at the outermost hop and set them yourself, so the app can trust them. Never append to a client-supplied value. - Consider validating that the HTTP host matches the TLS SNI on that connection and returning `421 Misdirected Request` when it does not. **In the application** - Build absolute URLs from a **configured canonical base URL** (`app.base-url=https://shop.example.com`), especially for anything that leaves the request/response cycle: emails, webhooks, stored links, signed callbacks. - If a per-tenant host is genuinely needed, resolve it from the *tenant record* keyed by an allowlist lookup, and reject requests whose host is not in the allowlist with 400/421. - Treat trusted-proxy configuration as security config: frameworks that honour forwarded headers (Spring's `ForwardedHeaderFilter`, Rails' `config.hosts`, Django's `ALLOWED_HOSTS`, Express `trust proxy`) must be told which upstreams to believe. Django's `ALLOWED_HOSTS` is the clearest example of the correct pattern: an explicit allowlist enforced before any handler runs. **At the cache** - Include the host in the cache key (most CDNs do by default; verify for multi-tenant setups). - Do not let unkeyed headers such as `X-Forwarded-Host` influence a cacheable response body. ## How to test it Send the request yourself and read the output: `curl -H 'Host: evil.example' https://…` against a staging host, then inspect any generated `Location`, canonical link, or email body. If the attacker's string appears, you have the bug. Repeat with `X-Forwarded-Host` and `Forwarded`, which are the versions people forget after fixing Host. ## The one-line rule Use the request host for **routing**; never for **authority**. Anything durable — an emailed link, a stored URL, a cached body, a redirect target — should come from configuration or an allowlist lookup.