HSTS Explained

HTTPS protects the connection between a browser and your server. HSTS protects the moment before that connection — when a user types example.com into the address bar without specifying a protocol, and the browser has to decide whether to make the first request over HTTP or HTTPS.

By default, browsers default to HTTP. They send the request unencrypted, get a 301 redirect to HTTPS, and continue securely from there. The first request, however, is in the clear — and that's enough for an attacker on the same network to intercept it, redirect the user to a fake HTTPS site, and harvest credentials. HSTS closes that gap.

What HSTS Does

HSTS is a single HTTP response header your server sends over HTTPS:

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

When a browser sees this header on an HTTPS response, it makes a note: "for this domain, never use HTTP — always upgrade to HTTPS automatically, for the next 31,536,000 seconds (one year)." Subsequent requests to example.com bypass the HTTP redirect entirely; the browser goes straight to HTTPS without ever sending a plaintext request.

This isn't just speed — it's a security improvement. Even if an attacker on a coffee-shop wifi tries to intercept the first request, the browser refuses to send it as HTTP. The connection either succeeds over HTTPS or fails entirely. There's no plaintext window for an attacker to exploit.

The Three Directives

max-age

How long the browser should remember the HSTS policy, in seconds. Common values:

• max-age=0 — disables HSTS for this domain (also tells the browser to forget any previous policy).
• max-age=300 — five minutes. Useful for testing — short enough to back out of if something breaks.
• max-age=86400 — one day. Sensible first deployment value.
• max-age=31536000 — one year. Required minimum for HSTS preload (more on that below).
• max-age=63072000 — two years. Common production value.

The clock resets every time a browser sees the header on a successful HTTPS response — so as long as visitors keep coming back, the policy stays current. Browsers cap maximum cache time around 2 years, so anything longer behaves the same as 2 years.

includeSubDomains

Without this, HSTS applies only to the exact host that sent the header. With it, the policy extends to every subdomain — www.example.com, api.example.com, blog.example.com, every host you'll ever spin up under that domain.

This is powerful and dangerous in equal measure. If you have an internal admin tool at internal.example.com that runs over HTTP only (a legacy app, a non-public dashboard, anything), includeSubDomains will break it for anyone who has previously visited example.com — the browser will refuse to make the HTTP connection.

Inventory all your subdomains before enabling includeSubDomains. Make sure every one of them is HTTPS-capable. Then enable.

preload

HSTS as described above has a chicken-and-egg problem: the very first request to a domain still happens over HTTP, before the browser has seen the HSTS header. Preload solves this by hardcoding the HSTS policy directly into browsers. When you submit your domain to the HSTS preload list, Chrome, Firefox, Safari, and Edge ship updates that include the entry — so even a fresh browser install on a new device will treat your domain as HTTPS-only from the very first request.

Preload is the strongest form of HSTS. It is also a one-way door, in practice. We'll come back to that.

How to Enable HSTS Safely

Don't jump straight to a one-year max-age with includeSubDomains and preload. Build up to it. The recommended sequence is:

1. Confirm everything works on HTTPS. Every page on the apex domain. Every subdomain you serve to users. Every API. Every redirect. Run SSL Checker on each hostname to confirm certificates and protocols look right.
2. Enable HTTP → HTTPS redirects everywhere. If any subdomain still serves plain HTTP, fix that first. HSTS without working HTTPS is just a way to break things.
3. Deploy with a short max-age. Start at max-age=300 (five minutes) without includeSubDomains. Watch logs and analytics for a day. If anything breaks, you can roll back and the policy expires in five minutes.
4. Increase to one day. max-age=86400. Watch for another few days.
5. Add includeSubDomains. Only if every subdomain is on HTTPS. If you're not sure, leave this off.
6. Increase to one week, then one year. max-age=604800, then max-age=31536000.
7. Submit to preload (optional, only when fully confident). Add preload to the header, set max-age=63072000, and submit at hstspreload.org.

The whole sequence can take 1–2 weeks if you're cautious, or a single afternoon if you're confident in your setup. There's no prize for moving fast.

How to Send the Header

nginx:

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

The always flag is important — without it, the header isn't sent on error responses (4xx, 5xx), which is technically a downgrade vector.

Apache:

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

You'll need mod_headers enabled (sudo a2enmod headers on Debian/Ubuntu).

Cloudflare: dashboard → SSL/TLS → Edge Certificates → HTTP Strict Transport Security. Cloudflare provides a UI that wraps the same parameters.

In all cases, make sure the header is only sent over HTTPS. Sending an HSTS header over plain HTTP has no effect — browsers ignore it as a security measure (an attacker could otherwise inject a header to lock the user out of HTTPS).

The Preload Trap

Preload is the only directive that's effectively permanent. Once your domain is in the preload list and that list is shipped in browser releases, your domain is HTTPS-only on every device that updates to those browser versions — and you cannot make those devices "forget" the entry.

You can submit a removal request, but:

• Removal takes weeks at minimum to propagate.
• Many users will hold old browser versions for months — those installs will continue enforcing the entry.
• Embedded devices, kiosks, IoT browsers, and corporate-locked installs may never update at all.

If you preload and then need to serve content over HTTP for any reason — moving to a new domain, decommissioning the site, supporting a legacy client — you can't. The right mental model is: preload is irreversible at internet scale. Only submit a domain you're confident will be HTTPS-only forever.

The other gotcha: with includeSubDomains; preload, every subdomain you create from now until the heat death of the universe must be HTTPS-capable. Want to spin up a quick HTTP-only test site at preview.example.com? Doesn't work — your own browser will refuse to load it. Want to use a third-party service that doesn't support HTTPS at tracking.example.com? Same problem.

For most apex domains running normal websites, this is fine. For complex orgs with many subdomains and shifting infrastructure, preload is a constraint to think about carefully before adopting.

Verifying HSTS Is Working

Once deployed, check that the header is actually being sent. The simplest test:

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

You should see your header come back exactly as configured. If it doesn't appear, common causes are:

• The header is set on the wrong virtual host or location block.
• A reverse proxy (Cloudflare, an internal load balancer) is stripping or overwriting headers.
• The always flag is missing on nginx and you're testing against an error response.
• The site is being served over HTTP and the HTTPS handler isn't actually being hit.

Browsers store HSTS state per-domain in their internal database. To inspect or clear it in Chrome, navigate to chrome://net-internals/#hsts — useful when you've deployed a config change and want to confirm the browser actually has the new policy without waiting for max-age to expire.

HSTS, SEO, and Search Engines

Search engines treat HSTS positively. Google has supported HTTPS as a ranking signal since 2014, and HSTS is a strong signal that your site is committed to HTTPS-only. We've never seen a ranking issue caused by HSTS itself — only by the underlying problem (broken HTTPS, expired certs, missing intermediates) that HSTS then makes more visible.

The one consideration: search engines re-crawl periodically. If you have HSTS enabled and your certificate later expires, Googlebot will fail to crawl those pages — and unlike a regular browser, it doesn't have a "proceed anyway" button. So HSTS makes good SSL hygiene more important, not less. Combine HSTS with monitoring; SSL Checker will tell you exactly what state the certificate is in.

The Practical Rule

If your site is already 100% HTTPS, enabling HSTS with a short max-age is a free security win. Build up to a year, add includeSubDomains once you've inventoried subdomains, and only consider preload if you're confident the domain will be HTTPS-only forever.

If your site has any HTTP fallback paths, mixed content issues, or unmaintained subdomains, fix those first. HSTS amplifies what's already there — it makes good HTTPS setups stronger and bad ones broken.