While Cross-Site Scripting (XSS) and SQL Injection often dominate security headlines, subtle logical flaws like Host Header Injection (HHI) and Open Redirects remain pervasive and highly exploitable. These vulnerabilities stem from a fundamental sin in web development: trusting user-controlled input to dictate server-side routing and URL generation.
Also See: Host Header Injection-Based Open Redirect
This guide provides a deep dive into the mechanics of these flaws, how they intersect, and the exact methodology security engineers and bug hunters use to find them. We will explore the deadly combination of host header injection open redirect attacks, how to test for them using Burp Suite and cURL, and how to permanently remediate them in your codebase.
To understand the vulnerabilities, we must first understand the HTTP mechanisms they abuse.
When a client makes an HTTP/1.1 request, it must include a Host header. This tells the web server (like Nginx or Apache) which virtual host should handle the request, especially when multiple domains share the same IP address.
GET /dashboard HTTP/1.1
Host: www.example.com
Servers use 301 (Moved Permanently) or 302 (Found) status codes, accompanied by a Location header, to tell the browser to navigate to a different URL. If the application dynamically constructs this Location URL using unvalidated user input, an Open Redirect is born.
Host Header Injection occurs when an application takes the user-supplied Host header and trusts it to generate absolute URLs, construct emails, or route traffic internally.
- Password Reset Poisoning: The app generates a reset link using the Host header. Attacker changes Host to evil.com. The victim receives an email with a link to evil.com/reset?token=xyz. The attacker captures the token and resets the victim's password.
- Web Cache Poisoning: If a CDN or reverse proxy caches responses based on the Host header, an attacker can inject a malicious Host, poison the cache, and serve XSS payloads to all subsequent users.
- Internal Routing Manipulation: The application uses the Host header to route requests to internal microservices. Injecting an internal hostname can lead to Server-Side Request Forgery (SSRF).
Open Redirects happen when an application includes a user-controllable URL in a redirect response without validating that the destination belongs to the application's own domain.
While parameter-based open redirects (?next=https://evil.com) are well known and often blocked by basic WAFs, advanced attackers look for header-based and path-based bypasses.
The most critical and often overlooked vulnerability occurs at the intersection of these two flaws: the host header injection open redirect chain. This happens when an application attempts to secure a redirect by checking if the URL is "relative" (starts with a /), but fails to account for the fact that the Host header can be manipulated to turn a relative URL into an absolute external redirect.
GET /logout?url=/ HTTP/1.1
Host: evil.com
The application constructs: http://evil.com/ and issues a 302 redirect. The host header injection open redirect chain is complete, bypassing the developer's allowlist logic entirely.
Detecting these flaws requires a mix of automated scanning and manual, logic-driven testing. Here is the standard operating procedure for penetration testers.
Use Burp Suite's "Param Miner" or "Host Header" extension to automatically inject alternative Host headers into every request. Look for reflections of the injected host in the HTTP response body (e.g., in password reset emails, canonical URLs, or footer links).
Map all endpoints that issue 301/302 redirects. Look for parameters like next, url, redirect, return_to, and continue. Test the following bypass payloads:
If you find an HHI, check if the response is cached. Send a request with a malicious X-Forwarded-Host or Host header containing an XSS payload. If subsequent normal requests (without the malicious header) return the XSS payload, you have successfully poisoned the web cache.
Fixing these vulnerabilities requires shifting from a "trust but verify" model to a strict "deny by default" model for all routing inputs.
- Never trust the Host header for URL generation: Hardcode the base URL in your application configuration (e.g., APP_BASE_URL=https://target.com) and use it for generating emails, canonical tags, and redirects.
- Validate Host at the Reverse Proxy: Configure Nginx/AWS ALB/Cloudflare to drop requests where the Host header does not match an explicit allowlist of your domains.
- Use Mapped IDs for Redirects: Instead of passing URLs in parameters (?next=/dashboard), pass mapped identifiers (?next=dashboard) and resolve them server-side against a strict allowlist.
- Use Framework Built-ins: If you must use relative redirects, use your framework's secure URL validation. In Django, use url_has_allowed_host_and_scheme(). In Spring, use UriComponentsBuilder with strict validation.
Historically, Open Redirects were considered low-severity (P4/P5) in bug bounty programs. However, in 2026, they are recognized as critical enablers for phishing. If an attacker can redirect a user from a trusted domain (e.g., bank.com/login?next=evil.com) to a malicious site, the user is highly likely to trust the phishing page. Furthermore, Open Redirects can be chained with OAuth flows to steal authorization codes, elevating them to High or Critical severity.
The Host header is a standard HTTP/1.1 header required for routing. The X-Forwarded-Host (XFH) is a non-standard header used by reverse proxies (like load balancers) to indicate the original host requested by the client. Applications often mistakenly trust XFH to reconstruct URLs. Attackers can inject malicious XFH headers directly. Secure applications must strip or strictly validate all proxy-related headers (X-Forwarded-Host, X-Forwarded-For, X-Forwarded-Proto) at the edge proxy level.
Cache poisoning via HHI occurs when the cache key includes the Host header, but the application reflects it unsanitized. To prevent this: 1) Configure your CDN/WAF to only cache responses for a strict allowlist of valid Host headers. 2) Ensure your application never reflects the raw Host header in the HTML body without context-aware encoding. 3) Use the Vary: Host header carefully, or better yet, rely on the CDN's native host-based cache partitioning.
A WAF is a good safety net, but it is not a replacement for secure coding. WAF rules for HHI typically involve validating the Host header against a regex allowlist. For Open Redirects, WAFs can block known malicious domains in redirect parameters. However, WAFs can be bypassed using encoding tricks, protocol-relative URLs, or obscure parameters. The root cause must be fixed in the application code by never trusting user input for routing or URL generation.
