HSTS Header: How Strict-Transport-Security Eliminates Redirect Hops

## Why it matters

HSTS is the rare header that deletes a redirect: the http-to-https hop stops happening at all for returning visitors, closing the SSL-stripping window the first insecure request opens. A visitor types http://example.com into the address bar. Without HSTS, the browser sends an unencrypted request, the server responds with a 301 to https, and the browser follows it. With HSTS learned, the browser upgrades the request before sending anything over the network.

The catch is its permanence. Once a browser learns HSTS for a host, it enforces the policy for the lifetime you set. If you add includeSubDomains, every subdomain gets the same policy for that duration. If you join the preload list, browsers ship the policy hard-coded in their code, so removal takes weeks or months. Get the rollout steps right, or you'll lock yourself into HTTPS longer than you want.

## How it works

The first HTTPS response carries the Strict-Transport-Security header. The browser stores the policy and the max-age lifetime. On every subsequent visit within that lifetime, before the browser issues any request, it checks the HSTS policy and upgrades http:// URLs to https:// internally. Chrome renders this as a 307 Internal Redirect in DevTools.

The directives are:

• max-age: the lifetime in seconds the policy is remembered (e.g., 31536000 for one year).
• includeSubDomains: if present, all subdomains of the host also get the policy.
• preload: permission to add this domain to the Chromium preload list, so browsers ship with the policy hard-coded.

The HSTS policy is scoped to the exact domain it was issued for. If the header comes from www.example.com, only www.example.com gets the policy. The policy only counts when served over HTTPS; an HSTS header on an HTTP response is ignored.

## What does not matter

HSTS does not affect the first ever visit to a domain without preload. The first request is still unencrypted (if the user types http://). HSTS protects subsequent visits. It also does not affect non-browser clients (curl, APIs, server-side libraries) unless they implement HSTS, which most do not.

The preload list is not a magic bullet. Submission requires a long max-age (typically 1 year minimum), includeSubDomains, and a way for browsers to contact you if there is a problem. Removal is slow: browsers may ship the policy for weeks after you request delisting.

## Code example

A minimal HSTS header for a new domain:

server {
  server_name example.com www.example.com;
  listen 443 ssl;
  
  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
  
  # Content here
}
Copy

A rollout ladder for a domain not yet on the preload list:

# Week 1: short lifetime, no subdomains, no preload
add_header Strict-Transport-Security "max-age=3600" always;

# Week 2: after monitoring, raise to one day
add_header Strict-Transport-Security "max-age=86400" always;

# Week 4: after no incidents, raise to one month
add_header Strict-Transport-Security "max-age=2592000" always;

# Month 3: includeSubDomains and higher lifetime
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# Month 6: add preload (requires the domain to have no subdomain issues)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
Copy

To verify HSTS is working, check DevTools:

1. First load of http://example.com: you see a 301 or 302 to https.
2. Reload or revisit: you see 307 Internal Redirect before the network request, confirming HSTS is active.

## How Scalpel shows it

An HSTS hint chip appears on any hop whose response carries Strict-Transport-Security, so you can confirm the policy is served on every host in the chain. The chip shows the header's presence and max-age, letting you verify the rollout is consistent across all entry points.