HTTP Redirect Security: Preventing Open Redirects and Hijacked Redirect Chains

What Are Open Redirects — and Why Do They Matter?

A redirect sends visitors from one URL to another. Done correctly, this is harmless — you redirect HTTP to HTTPS, or www to the bare domain. Done incorrectly, redirects can be weaponised.

An open redirect is a redirect where the destination URL is controlled by user input. For example:

https://yoursite.com/go?url=https://attacker.com

If your server follows that URL without checking it, an attacker can use your domain as a trusted-looking launchpad to phish your users. The victim sees your domain in the link, trusts it, clicks it, and lands on a fake login page.

When WebSentry scans your site, the redirects check looks at whether your redirect chain is clean, avoids mixed-content hops, and doesn't expose open redirect behaviour.

The Four Redirect Problems That Actually Get Exploited

1. Open Redirects

Any endpoint that takes a destination URL as a parameter and redirects without validation is an open redirect. Common patterns that introduce this:

• ?next=, ?return_to=, ?redirect=, ?url= parameters
• OAuth flows that bounce through an unvalidated return URL
• Login pages that redirect users to wherever they came from without checking the domain

Fix: Only redirect to relative paths or to an allowlist of known domains. Never follow an arbitrary URL from user input.

2. HTTP to HTTPS Redirect Misconfiguration

Your HTTP-to-HTTPS redirect should be a single permanent redirect (301 or 308). If it's a 302 (temporary), browsers won't cache it and users will hit HTTP first every time — leaving a window for MITM attacks.

Fix: Use 301 for HTTP→HTTPS and combine it with an HSTS header so browsers skip the HTTP hop entirely on subsequent visits.

3. Mixed-Protocol Redirect Chains

Redirect chains that go HTTP → HTTP → HTTPS, or HTTPS → HTTP → HTTPS, expose traffic to interception mid-chain. Even one unencrypted hop is enough for an attacker on the same network.

Fix: Keep redirect chains to a single hop. Go directly from the source to the final HTTPS destination.

4. Redirect Loops

A redirect loop (A → B → A) isn't a security issue per se, but it breaks your site for users and search engines, and often signals a misconfiguration that a security audit should flag.

How to Test Your Redirects

Run a free WebSentry scan to check your redirect chain automatically. For manual testing:

• Use curl -I http://yourdomain.com — check the status code (should be 301, not 302) and that the Location header points to HTTPS
• Try https://yourdomain.com/go?url=https://google.com — if it redirects to Google, you have an open redirect
• Check your login and OAuth flows for next= or return_to= parameters that accept external URLs

Fixing Open Redirects in Common Frameworks

Node.js / Express

// Only redirect to relative paths
const dest = req.query.next || '/dashboard';
const safe = dest.startsWith('/') && !dest.startsWith('//') ? dest : '/dashboard';
res.redirect(safe);

PHP

$allowed = ['https://yoursite.com/dashboard', 'https://yoursite.com/profile'];
$dest = $_GET['next'] ?? '/dashboard';
if (!in_array($dest, $allowed)) {
    $dest = '/dashboard';
}
header('Location: ' . $dest);

Django

from django.utils.http import url_has_allowed_host_and_scheme

next_url = request.GET.get('next', '/')
if not url_has_allowed_host_and_scheme(next_url, allowed_hosts={request.get_host()}):
    next_url = '/'
return redirect(next_url)

Summary

Clean redirect behaviour is simple to verify and cheap to fix. The rule is: never let user-controlled input determine where your server sends a visitor. Validate destination URLs against a whitelist, use permanent redirects for HTTP→HTTPS, and keep redirect chains to one hop. Run a WebSentry scan to confirm your setup is clean.