What Is HSTS? includeSubDomains, preload and the Common Pitfalls

Q: Which max-age should I choose?

For production 31536000 (one year) is recommended. When testing a new HSTS setup, start with a low value such as a week and raise it once you are sure everything works.

A 301 redirect from HTTP to HTTPS sounds safe — but the first unencrypted visit is still vulnerable to a man in the middle. HSTS closes that gap by telling the browser: never use HTTP for this domain again. Here is how the header works, what the three directives mean, and the pitfalls that can lock a whole domain out for months.

Short answer

HSTS (HTTP Strict Transport Security) is an HTTP header that instructs the browser to always use HTTPS for a domain for a stated period (max-age), even if the user types http:// or clicks an HTTP link. It eliminates the vulnerable first unencrypted visit and protects against SSL-stripping attacks. The important directives are max-age, includeSubDomains and preload — and the latter two must be handled with care.

The problem HSTS solves

Even with a perfect HTTP-to-HTTPS redirect there is a gap: the very first request goes over HTTP, before the redirect arrives. An attacker on the network (an open WiFi) can intercept that request and run an SSL-stripping attack — keeping the user on HTTP and relaying unencrypted. HSTS closes the gap: after the first visit the browser remembers that the domain may only be accessed over HTTPS, and itself upgrades all future HTTP attempts to HTTPS internally before anything is sent. It complements the redirect described in HTTPS explained.

The header and its directives

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

max-age — how long (in seconds) the browser should remember to use HTTPS only. 31536000 is one year, the recommended production value.
includeSubDomains — apply the rule to all subdomains, not just the domain that sent the header.
preload — signal that the domain may be added to the browser's built-in preload list, so HTTPS applies from the very first visit.

How to set the header

# nginx — set HSTS only on the HTTPS server, never on port 80
server {
    listen 443 ssl;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

The trailing always ensures the header is also sent on error responses. Never set the HSTS header on an HTTP response — it is ignored anyway and is a sign of misconfiguration.

Pitfall 1: includeSubDomains hits everything

If you set includeSubDomains, the HTTPS enforcement applies to every subdomain — including internal tools, legacy systems or test subdomains that may run HTTP only. If even one of them lacks a valid certificate, it becomes unreachable in the browser until max-age expires. Map all subdomains before enabling the directive.

Pitfall 2: preload is hard to undo

Getting onto the preload list is easy; getting off it is slow. The list is hard-coded into browsers and only updated with new browser releases, so removal can take months. Never submit a domain to the preload list before:

All subdomains have valid certificates and run HTTPS.
You are sure the entire domain must remain HTTPS-only indefinitely.
You have tested with a lower max-age first (e.g. a week) before raising it to one year.

Pitfall 3: an expired certificate becomes fatal

Without HSTS, a user can in an emergency click past a certificate warning. With HSTS the browser removes that option — an expired or failing certificate makes the site completely unreachable, with no way around it. HSTS therefore raises the stakes on certificate monitoring considerably: a certificate you could previously renew with a little delay now becomes hard downtime the moment it expires.

How CertControl supports a safe HSTS rollout

HSTS is only safe if the certificates never fail — and includeSubDomains means all subdomains must be healthy. CertControl discovers your subdomains via Certificate Transparency and DNS, validates the certificate and chain on each endpoint, checks whether the HSTS header is set, and warns in good time before a certificate expires — precisely because an expiry under HSTS gives no grace period. HSTS is the final lock on top of a correct TLS handshake and a clean HTTPS redirect.

Frequently asked questions

What is the difference between an HTTPS redirect and HSTS?

A redirect sends the user from HTTP to HTTPS, but the first request still goes over HTTP and can be intercepted. HSTS makes the browser upgrade to HTTPS internally before anything is sent — so the vulnerable first visit disappears after the first time.

What does includeSubDomains do?

It extends the HTTPS enforcement to all subdomains under the domain. It is powerful but dangerous: if even one subdomain runs without a valid certificate, it becomes unreachable until max-age expires. Map all subdomains first.

Should I use preload?

Only when you are completely sure. The preload list is hard-coded into browsers, and removal can take months. Make sure the whole domain and all subdomains are HTTPS-only and will remain so before submitting the domain to the list.

Which max-age should I choose?

For production 31536000 (one year) is recommended. When testing a new HSTS setup, start with a low value such as a week and raise it once you are sure everything works.

What happens to HSTS if my certificate expires?

The site becomes completely unreachable in the browser, with no option to click past the warning. That is why certificate monitoring is critical when HSTS is active — an expiry gives no grace period.

See the platform Book a demo

What is HSTS?