HSTS header and secure transport

The problem HSTS solves

An HTTP to HTTPS redirect is a recommendation, not a guarantee. The first request of a session can still go out in clear text (port 80) before the redirect kicks in, and an attacker on the path can intercept that first hop, block the redirect, and serve a fake page. HSTS removes that window: the server tells the browser to remember, for a given period, that this domain must only ever be reached over HTTPS, so even a future plain-HTTP attempt is upgraded internally before anything leaves the machine.

Strict-Transport-Security: max-age=31536000; includeSubDomains is the header a server sends on an HTTPS response.

The two-stage adoption

HSTS is safe when the zone is prepared, and fatal when it is not:

1. Run HTTPS fully first. Every page, every request on the secure hostname, and all subdomains in includeSubDomains must serve HTTPS without mixed content. Check the existing HTTPS implementation against the mixed content article.
2. Send a short max-age first (say 300). Confirm the site still works over HTTPS, that no subdomain unexpectedly 301s to HTTPS that is not ready, and that the certificate chain covers every hostname. Then raise to 31536000.
3. For preload: after the period at long max-age, submit the domain to the HSTS preload list checklist once it shows fully green, because the preload entry survives even after the header is removed.

The failure to roll out in stages converts a configuration error at step two into a lockout that lasts the entire max-age.

How a site owner forces it

At the edge, the easier and common path is to let the CDN or hosting layer add the header. On Cloudflare, "Always Use HTTPS" plus the "HSTS" option under TLS sets max-age and includeSubDomains proxied for the whole zone. On nginx, the header is added at the server block:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

The always / always set matters: without it, some servers omit the header on 4xx/5xx responses, and a cached 404 would not renew the policy. Test with:

curl -sI https://example.com | grep -i strict

The hazards in practice

• A subdomain or a CDN without HTTPS under includeSubDomains is a soft lock: any visit to that subdomain becomes an HTTPS request the server cannot serve, and the browser shows the certificate error.
• A site behind a CDN you later remove still has the header baked into the CDN; stripping the CDN leaves the header gone and the browser's remembered policy remains until expiry.
• Preload is opt-in by name only. It works from the very first visit (no relying on the response) but decides on a miss against the whole list, so a temporarily broken cert chain during the preload window can bake a bad policy for months.

When to avoid HSTS

• Sites with half the traffic served over plain HTTP (a login portal behind a corporate proxy, part of a domain without HTTPS readiness).
• Sites that serve an HTTP-only hostname (a staging host, a content part that will never be HTTPS, an internal admin that sits on port 80).
• Sites behind a captive-portal redirect (hotel, airport) that break HTTPS enforcement on first-connect; those need a host network that traps HTTP first, not an enforced HSTS.

The HTTP scheme choice and SEO impact articles address whether 301 or HSTS matters in a given deployment. The certificate errors article is the list of what an unsolved HSTS lockout looks like from the browser side.