HSTS and the HSTS preload list

Why HTTPS alone is not enough

Most visitors reach a site by typing a name or following an old link that starts with http://. The server then redirects to HTTPS, but that first plain request can be intercepted on a hostile network. An attacker in the middle can keep the victim on HTTP and proxy the real site, a technique known as SSL stripping.

HTTP Strict Transport Security (RFC 6797) closes that gap for returning visitors. After a browser has seen the Strict-Transport-Security header over a valid HTTPS connection, it rewrites every future request for that host to HTTPS internally, before anything goes on the network. It also refuses to let the user click through certificate errors for that host.

The header

Strict-Transport-Security: max-age=31536000; includeSubDomains

Browsers ignore the header when it arrives over plain HTTP, because an attacker could inject it there. Send it on HTTPS responses only, and on every response, including redirects and error pages, so the policy is refreshed whatever page a visitor hits.

server {
    listen 443 ssl;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

<VirtualHost *:443>
    ServerName example.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

Rolling out HSTS safely

The risk with HSTS is not the header itself but its memory. If you set a year-long policy and later need plain HTTP on that host, or a certificate lapses, browsers that saw the header will refuse to connect until the policy expires. A staged rollout finds those problems while max-age is still short.

Before step 3, list every subdomain that exists in DNS and check that each one works over HTTPS with a valid certificate. The DNS Lookup and your DNS zone export are the starting point; do not forget printers, old intranet names and staging hosts that only people inside the company use.

Communicate each stage to the teams that run subdomains. A short note with the date and the planned max-age gives them a chance to raise an HTTP-only service before it breaks.

Check the header on your real responses with the HTTP Headers Checker. It reports the max-age in days and whether includeSubDomains and preload are present.

What includeSubDomains can break

includeSubDomains set on example.com applies to every name under it, including ones served by other teams or vendors. Any subdomain that must still be reached over plain HTTP becomes unreachable for browsers that have the policy. Typical victims are internal tools, network devices with self-signed certificates and legacy marketing microsites.

• Internal hosts such as intranet.example.com served over HTTP inside the office network.
• Devices with self-signed certificates, because HSTS removes the click-through option.
• Vendor-hosted subdomains (help centres, status pages) where you do not control the certificate.
• Captive portals or HTTP-only APIs on subdomains used by old clients.

The header is only honoured for the host that sent it and its subdomains. A policy with includeSubDomains sent by www.example.com covers *.www.example.com, not api.example.com. To cover the whole domain, the header must be sent by example.com itself, which means users need to visit the bare domain at least once, or the domain must be preloaded.

The preload list

HSTS protects a browser only after its first successful HTTPS visit. The preload list removes that first-visit gap: it is a list of domains compiled into Chromium and also used by Firefox, Safari and Edge, which treat those domains as HSTS from the start. Domains are submitted through hstspreload.org, which checks the requirements automatically.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Some top-level domains are preloaded as a whole, so every domain registered under them requires HTTPS in browsers from the first visit. If you use such a TLD, HSTS behaviour is already in place regardless of your header, and plain HTTP subdomains will not work.

Redirects that work with HSTS

A clean redirect chain matters for both HSTS and preloading. The recommended sequence is: http://example.com → https://example.com (setting HSTS for the bare domain) → https://www.example.com if you use www. Redirecting straight from http://example.com to https://www.example.com skips the bare domain's HTTPS response, so it never sends its policy.

http://example.com/        301 → https://example.com/
https://example.com/       301 → https://www.example.com/   (with Strict-Transport-Security)
http://www.example.com/    301 → https://www.example.com/
https://www.example.com/   200                               (with Strict-Transport-Security)

The Redirect Checker follows the chain from http:// and lists every hop, which makes it easy to confirm the first hop stays on the same host. The redirect guide covers loops and unnecessary hops.

Common mistakes

The last row is common behind CDNs and reverse proxies: the application sends one value and the edge adds another. Decide which layer owns security headers and remove the other, then confirm the final response from outside with the HTTP Headers Checker.

HSTS and related mechanisms

Several newer features also push browsers toward HTTPS, and it helps to know how they relate. None of them replaces HSTS for a site you control, but they change what visitors experience on sites without it.

HSTS remains the mechanism you control that makes certificate errors non-bypassable and protects returning visitors on every browser that implements it. The others are useful additions, and upgrade-insecure-requests in particular pairs well with HSTS during clean-up of old content.

Living with HSTS

HSTS turns certificate problems into outages. Automate renewal, monitor expiry separately, and test renewals on staging hosts. A lapsed certificate on a site without HSTS shows a warning; on a site with HSTS, visitors simply cannot get in.

• Monitor certificate expiry for every host covered by the policy, including subdomains.
• Add new subdomains only with HTTPS from day one.
• Keep the header on every HTTPS response, including CDN edge responses.
• Document that the domain is HSTS or preloaded, so future teams do not plan HTTP-only services on it.
• Pair HSTS with the other security headers; the CSP guide covers the most complex one.

Large organisations often have many domains, and HSTS decisions differ per domain. A product domain with a single web application is an easy candidate for a long max-age and preloading; a corporate domain with dozens of internal subdomains may only be ready for HSTS on specific hosts without includeSubDomains. Record the decision and its reasons per domain, so the next team knows what is safe.

When you acquire or inherit a domain, check whether it is already preloaded or sends HSTS before planning services on it. The HTTP Headers Checker shows the current header, and the preload site shows the list status. Discovering a preloaded domain after building an HTTP-only service on one of its subdomains is an avoidable surprise.

If you ever have to back out, send max-age=0 over HTTPS. Browsers that receive it forget the policy for that host. Visitors who do not return before their stored max-age expires keep the old policy until then, which is another reason to raise max-age gradually.

FAQ

Sources

• RFC 6797: HTTP Strict Transport Security (HSTS)
• HSTS Preload List submission and requirements
• MDN: Strict-Transport-Security
• nginx documentation: add_header