On this page
Worried a redirect on your site can be hijacked? Run the free scan at scan.sumrite.com to flag redirect and header issues, no account needed.
Every HTTP request carries a Host header that names the site the client is asking for. It is useful and necessary, but it has one property developers forget: the client sends it, so the client controls it. Treating it as trusted input is the root of a family of problems, and the most common one we report is an open redirect.
How the redirect goes wrong
Many applications redirect users as a matter of course: after login, after a language switch, from a bare path to a canonical one. To build the destination, some code reads the Host header and stitches together an absolute URL from it, rather than using a hostname the server already knows.
When that happens, the destination of the redirect is decided by a value the requester controls. A request that keeps the real path but carries a Host header pointing at a different domain produces a 302 response whose Location points at that different domain, with your path appended. The server has effectively been told “redirect to this path” and has filled in the hostname from the one piece of the request it should not have trusted.
The link looks legitimate, and that is the point
The victim clicks a link that genuinely points at your domain. Their browser follows the redirect to the attacker’s lookalike domain, which can carry the same path so the page looks like a deep link into your site. Nothing in the original link looks wrong, which is exactly why open redirects make phishing so effective.
Why a “harmless” redirect is worth fixing
On its own, a redirect to another site is often scored as lower severity. The reason it still matters is that it is a dependable building block for more serious attacks:
- Convincing phishing. The email or message links to your real domain, which passes the glance test and many link filters. The redirect does the rest.
- Stealing tokens in authentication flows. OAuth and single sign-on pass codes and tokens through redirect URLs. Password-reset and email-verification flows do the same. If a redirect target can be influenced, those secrets can be routed to an attacker’s host, which can escalate to full account takeover.
- Other uses of the same root cause. An application that trusts the
Hostheader for redirects often also trusts it when it builds password-reset links or caches responses, which can lead to poisoned reset emails or cache poisoning. The redirect is frequently the first visible symptom of a broader habit of trusting the header.
That is why a penetration test reports an attacker-controllable redirect even when, in isolation, it “only redirects”. The value is in what it enables next.
The root cause: trusting a client-supplied value
The Host header is not an identity your server issues. It is part of the request, so a client can set it to anything. Two assumptions turn that into a vulnerability:
- “The Host header is always our domain.” It is whatever the requester sends. Proxies and load balancers can also forward
X-Forwarded-Host, which inherits the same problem. - “A redirect only sends people where we tell it to.” It sends them wherever the
Locationheader points, and if that was built from untrusted input, the attacker told it where to go.
How to fix and prevent it
- Never build redirects from the Host header. Decide the canonical hostname in server configuration or application settings and use that value when you need an absolute URL.
- Prefer relative redirects. Redirecting to a path such as
/dashboardrather than a full URL removes the chance to send users off-site entirely. - Allowlist redirect targets. Where an absolute URL is unavoidable, check it against a short list of hostnames you own before issuing the redirect, and fall back to a safe default otherwise.
- Validate the incoming Host. At the web server or framework level, accept only your known domains and return a default response for anything else, so a spoofed
Hostnever reaches application logic. Apply the same rule toX-Forwarded-Host. - Protect authentication flows specifically. Register exact, fixed redirect URIs for OAuth and SSO, and build password-reset and verification links from the canonical domain, never from the request.
- Test it. Confirm the fix holds by trying spoofed
HostandX-Forwarded-Hostvalues and checking that redirects stay on your domain.
Where this fits
Open redirection sits alongside the other request-trust issues we cover, such as CORS reflecting any origin. Confirming that a redirect is genuinely attacker-controllable, and then showing how far it chains, for example into an authentication flow, is manual work. A scanner can flag a suspicious redirect; it takes a tester to prove impact, which is the difference our web application VAPT is built around.
How Summit helps
Summit’s web application VAPT and API security testing check how your application handles the Host header across redirects, links, password-reset flows and caching, and whether a spoofed value can be turned into something that hurts your users. We confirm each finding by hand, show the realistic chain and give you a fix and a retest. Scanner-level checks are free at scan.sumrite.com.
Flag redirect issues, then confirm them
Run the free scan at scan.sumrite.com to flag redirect and header issues, then bring us the ones that need a person to confirm and chain. Get a quote.
Related reading: CORS misconfiguration: reflecting any origin · CSP unsafe-inline and unsafe-eval risks · What makes a VAPT report worth paying for
Frequently asked questions
What is host header injection?
A class of issue where an application trusts the incoming HTTP Host header as if it were reliable, and reuses it to build URLs, links or redirects. Because the Host header is sent by the client, an attacker can set it to a value the application did not intend.
How does host header injection cause an open redirect?
If the application builds a redirect target from the Host header, a request with a spoofed Host header produces a redirect to that spoofed domain. A victim who follows a link to the real site can be bounced to an attacker-controlled domain, while the path and parameters look legitimate.
Why is an open redirect dangerous?
The starting link is genuinely on your domain, so it passes the quick checks people and filters make. The redirect then lands the victim on a lookalike page for phishing, or is chained with other flaws such as stolen OAuth tokens or password-reset links that leak to the attacker's host.
How do I fix host header injection?
Do not build redirects or links from the Host header. Configure the application's canonical domain server-side and use it, validate the incoming Host against an allowlist of expected domains, and reject or return a default response for anything else. Redirect only to relative paths or an allowlist of known URLs.
Is an open redirect really a vulnerability if it just redirects?
On its own it is often rated lower severity, but it is a reliable building block. It makes phishing far more convincing and is frequently chained into account takeover through OAuth or password-reset flows, so it is worth fixing rather than dismissing.
How do I check my site for this?
Summit's free scan at scan.sumrite.com flags redirect and header issues it can detect automatically. Confirming that a redirect is genuinely attacker-controllable, and chaining it, is manual work our team does in a penetration test.
