Why Your HTTPS Redirect Chain Matters for Security

What is a redirect chain#

A redirect chain is the sequence of HTTP responses with 3xx status codes that a browser follows before it receives the final page. When you type example.com into your browser, the server might respond with a 301 pointing to https://example.com, which then sends another 301 to https://www.example.com. That is a two-step redirect chain.

http://example.com
  → 301 → https://example.com
    → 301 → https://www.example.com
      → 200 OK (final page)

Redirects serve legitimate purposes. They consolidate domain variants, enforce HTTPS, and handle URL changes after site migrations. The security concern is not that redirects exist, but how they are configured. A single redirect from HTTP to HTTPS on the same host is fine. A chain that bounces between protocols, crosses through third-party domains, or uses temporary status codes introduces real risk.

The security risk in the first hop#

The most dangerous moment in any redirect chain is the first request over HTTP. When a user types your domain without the https:// prefix, or clicks a link that uses http://, the browser sends a plain text request. That request contains the full URL, any cookies the browser has for your domain, and the user's IP address. All of it is visible to anyone on the network.

This is where SSL stripping attacks happen. An attacker positioned between the user and the server (on public Wi-Fi, a compromised router, or through ARP spoofing on a local network) intercepts the HTTP request before it reaches your server. The attacker connects to your server over HTTPS, fetches the content, and sends it back to the user over HTTP. The user sees the site load normally, but the connection never upgrades to HTTPS. Every form submission, every page navigation, every keystroke is visible to the attacker.

1. User types example.com
2. Browser sends GET http://example.com (plain text)
   ← Attacker intercepts this request
3. Attacker forwards request to https://example.com
4. Server responds with page content over HTTPS
5. Attacker strips HTTPS, sends HTTP version to user
6. User sees the site on HTTP — all traffic is exposed

The redirect itself is your server's attempt to upgrade the connection. The problem is that this attempt happens after the user has already sent an unencrypted request. The attacker simply prevents the redirect from reaching the user.

This is why HSTS (HTTP Strict Transport Security) exists. When a browser has seen an HSTS header from your site, it will never send an HTTP request to your domain. It upgrades to HTTPS internally before anything leaves the browser. But HSTS only works after the first visit. On the very first visit, the browser has no memory of your HSTS policy, so the initial HTTP request still goes out unencrypted. That first-visit gap is what the HSTS preload list closes.

How cookies leak through HTTP hops#

When a browser follows a redirect, it includes cookies in the request to the new URL, as long as the cookies match the domain and path. If any redirect hop in the chain uses HTTP, cookies without the Secure flag will be sent in plain text.

The Secure flag tells the browser to only send the cookie over HTTPS connections. Without it, the browser will attach the cookie to any request for that domain, including HTTP requests during a redirect. Session tokens, authentication cookies, and tracking identifiers can all be captured this way.

Even if you set the Secure flag on all your cookies, an HTTP hop in the redirect chain is still a problem. Attackers can inject new cookies through an HTTP response (a technique called cookie injection), potentially overwriting legitimate cookies with malicious values. This can be used to fix a user's session to one the attacker controls.

The fix is straightforward: make sure every hop in your redirect chain uses HTTPS, and set the Secure flag on all cookies. These two measures together prevent both cookie leakage and cookie injection during redirects.

Redirect chains and HSTS preload#

The HSTS preload list is a registry of domains that browsers treat as HTTPS-only from the very first connection. Getting on the list eliminates the first-visit vulnerability where a browser might send an initial HTTP request. But preload submission has strict requirements, and your redirect chain is one of them.

To qualify for HSTS preload, your redirect chain must follow a specific pattern. The HTTP version of your bare domain must redirect directly to the HTTPS version of the same domain. From there, you can redirect to www or any other subdomain. But the first hop must go from http:// to https:// on the same host, and the HSTS header with includeSubDomains and preload directives must be present on that HTTPS response.

# Valid for preload submission:
http://example.com
  → 301 → https://example.com          ← HSTS header here
    → 301 → https://www.example.com    ← also has HSTS header
      → 200 OK

# HSTS header on the HTTPS responses:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

A common mistake is redirecting from http://example.com directly to https://www.example.com, skipping the HTTPS version of the bare domain. This breaks preload validation because the validator needs to see the HSTS header on https://example.com specifically.

# Fails preload validation:
http://example.com
  → 301 → https://www.example.com    ← skips https://example.com
    → 200 OK

# Problem: the HSTS header on https://example.com
# is never served because the redirect skips it

Common redirect misconfigurations#

These are the redirect chain problems that show up most often in security audits and scans.

Using 302 instead of 301 for HTTPS upgrades

A 302 redirect is temporary. It tells the browser "this page has moved for now, but check back later." For an HTTP to HTTPS upgrade, this is the wrong signal. The browser will repeat the HTTP request on every visit because it does not cache temporary redirects. A 301 (permanent) redirect tells the browser to remember the upgrade and go directly to HTTPS next time, reducing the exposure window to a single visit.

Multiple unnecessary hops

Some sites redirect three or four times before reaching the final URL. A common pattern is http://example.com to http://www.example.com to https://www.example.com. That second hop is on HTTP and completely unnecessary. The server should redirect directly from HTTP to HTTPS.

# Insecure: second hop is HTTP
http://example.com
  → 301 → http://www.example.com     ← still HTTP!
    → 301 → https://www.example.com
      → 200 OK

# Secure: upgrade to HTTPS immediately
http://example.com
  → 301 → https://example.com
    → 301 → https://www.example.com
      → 200 OK

Redirects through third-party domains

Marketing tools, link shorteners, and CDN configurations sometimes insert intermediate redirects through external domains. When your redirect chain passes through a domain you do not control, you are trusting that domain with your users' cookies and request data. If the third party has a security issue, your users are affected.

Redirect loops

Misconfigured servers can create infinite redirect loops, where the HTTP version redirects to HTTPS, which redirects back to HTTP. This often happens when a reverse proxy or load balancer terminates SSL and the application server does not know the original request was HTTPS. The application sees an HTTP request and issues a redirect, which the proxy upgrades, which the application redirects again. Browsers will stop following redirects after about 20 hops and show an error.

How to fix your redirect chain#

A secure redirect chain follows three rules: upgrade to HTTPS on the first hop, use 301 status codes for permanent redirects, and minimize the total number of redirects.

# Redirect HTTP to HTTPS (same host, then www)
RewriteEngine On

# Step 1: Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

# Step 2: Redirect bare domain to www (on HTTPS)
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

# HTTP → HTTPS (same host)
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# Bare domain → www (HTTPS)
server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    return 301 https://www.example.com$request_uri;
}

# Main server block
server {
    listen 443 ssl;
    server_name www.example.com;
    # SSL certificate and site configuration here
}

// Middleware: redirect HTTP to HTTPS and non-www to www
app.use((req, res, next) => {
  // Force HTTPS
  if (req.headers['x-forwarded-proto'] !== 'https') {
    return res.redirect(301, `https://${req.headers.host}${req.url}`);
  }

  // Redirect bare domain to www
  if (req.hostname === 'example.com') {
    return res.redirect(301, `https://www.example.com${req.url}`);
  }

  next();
});

How to audit your redirect chain#

You can inspect your redirect chain using command-line tools or a web-based scanner. The goal is to see every hop, confirm each one uses HTTPS, check the status codes, and verify that HSTS headers are present.

# Follow redirects and show each hop
curl -ILs http://example.com 2>&1 | grep -E 'HTTP/|Location:'

# Example output:
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: https://www.example.com/
# HTTP/2 200

When reviewing the output, look for these warning signs:

• Any Location header pointing to an http:// URL after the first hop
• Status code 302 or 307 on what should be a permanent HTTPS redirect
• Redirects through domains you do not own or control
• More than two total redirects before reaching the final URL
• Missing Strict-Transport-Security header on the HTTPS responses

SiteSecurityScore's scanner automatically traces and displays the full redirect chain for any domain you scan. Each hop shows the status code, protocol, and destination URL, making it easy to spot HTTP hops or unnecessary intermediaries without running command-line tools.

Test all four entry points for your domain: http://example.com, http://www.example.com, https://example.com, and https://www.example.com. A misconfiguration on just one of these can leave a gap even if the other three are correct.

Frequently asked questions#