Host Header Injection
debt(d5/e3/b3/t9)
Closest to 'specialist tool catches it' (d5). The detection_hints.tools list includes semgrep and owasp-zap — both specialist tools. Semgrep requires a custom or community rule to flag `$_SERVER['HTTP_HOST']` usage in sensitive contexts; owasp-zap can detect it via active scanning. Neither is a default linter catch, so d5 is the right anchor.
Closest to 'simple parameterised fix' (e3). The quick_fix is to maintain an allowlist of valid hostnames and validate `$_SERVER['HTTP_HOST']` against it — a small, localised change. The common_mistakes point to a pattern (unsanitised HTTP_HOST in password reset URLs, redirects, cached responses) that can be fixed by introducing validation in one or a few places. It doesn't require cross-cutting architectural rework, but it's more than a single one-line swap because the pattern may appear in several places (password reset, email verification, URL generation).
Closest to 'localised tax' (b3). The applies_to scope is web and API contexts. The fix — an allowlist validation — is localised to URL-generation and redirect logic. It imposes a small persistent check requirement on those paths, but doesn't reshape the entire codebase or create gravitational pull on unrelated components.
Closest to 'catastrophic trap' (t9). The misconception field states exactly this trap: developers believe the Host header is set by the server and can be trusted, when in reality it is freely forgeable by the client. This is a deeply counterintuitive inversion — the 'obvious' assumption (server controls Host) is always wrong in HTTP, and the consequence (password-reset link poisoning, cache poisoning) is severe. This matches t9: the obvious way is always wrong.
Also Known As
TL;DR
Explanation
Many PHP applications use $_SERVER['HTTP_HOST'] to construct absolute URLs for password-reset emails, redirect targets, or canonical links. Because the Host header is fully controlled by the client (and can be spoofed or overridden via X-Forwarded-Host in proxied environments), an attacker can inject a malicious host to redirect password-reset links to their own server. Mitigations include maintaining an explicit allowlist of valid hostnames and validating $_SERVER['HTTP_HOST'] against it.
Common Misconception
Why It Matters
Common Mistakes
- Using $_SERVER['HTTP_HOST'] to build password reset or email verification links without validation.
- Trusting X-Forwarded-Host from reverse proxies without a strict allowlist.
- Generating absolute URLs in cached responses using the Host header — poisons the cache for other users.
- Not configuring a trusted_hosts or allowed_hosts list in the application or framework.
Code Examples
$resetLink = 'https://' . $_SERVER['HTTP_HOST'] . '/reset?token=' . $token;$resetLink = 'https://www.example.com/reset?token=' . $token; // hardcode trusted origin