What Is HSTS (and Why Your HTTPS Isn't Enough)?

Quick answer
HSTS (HTTP Strict Transport Security) instructs browsers to only ever connect to your site over HTTPS.
It closes the window where a user typing your domain or clicking an http:// link gets served a downgraded connection.
The header is one line, but set it with a short max-age first, then increase once you’ve confirmed nothing breaks.

What problem does HSTS solve?

Even with HTTPS enabled, a browser will happily follow an http:// link or a user-typed domain over plain HTTP first, then redirect. In that window an attacker on the network can intercept the request, strip the redirect, and serve a fake page or downgrade the connection — the classic SSL stripping attack. HSTS tells the browser, after the first visit, to refuse plain HTTP for your domain entirely and to upgrade to HTTPS automatically, so the insecure window never opens.

How do I enable HSTS?

Send the Strict-Transport-Security header from your HTTPS responses. Start with a short max-age (a few hours or a day) to make sure nothing depends on plain HTTP — mixed content or http:// links to your site — then raise it to six months to a year. Include includeSubDomains once subdomains also support HTTPS, and consider preload, which hardcodes your domain into browsers and eliminates even the first-request window — but preload is hard to undo, so only do it when you’re certain.

# nginx: send HSTS on every HTTPS response\nadd_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;\n# Start with max-age=86400, verify for a day, then increase.

What is HSTS preload?

Preload submits your domain to a list baked into browsers (hstspreload.org). Browsers on the list refuse plain HTTP for your domain from the very first visit — no prior HSTS header required. The catch: removal takes months, so preload locks you into HTTPS permanently. Enable it only after confirming every subdomain serves valid HTTPS; otherwise you can break http-only services that share the domain.

Where this bites vibecoders
The AI-generated site has HTTPS working, so the assistant declares victory — but without HSTS, every user whose bookmark or link says http:// still makes that first insecure connection. The header is one line and the deployment cost is zero, which makes its absence a pure knowledge gap. The safe rollout (short max-age first, then escalate) is exactly the kind of cautious sequence an assistant skips in favor of ‘just add the header’.

Where AI coding assistants get this wrong

Adding HSTS with a year-long max-age on the first deploy, before verifying no http:// dependencies exist.
Sending HSTS over plain HTTP, which browsers ignore (it must be sent over HTTPS).
Adding includeSubDomains when some subdomains don’t support HTTPS, breaking them.
Recommending preload without explaining it’s hard to reverse.

Checklist

Send Strict-Transport-Security over HTTPS on every response.
Roll out with a short max-age, verify, then increase to 6-12 months.
Add includeSubDomains only after all subdomains serve valid HTTPS.
Use preload only when you’re certain HTTPS is permanent for the whole domain.

FAQ

Does HSTS work on the first visit?

Only with preload. Without preload, the browser learns HSTS from the header on a prior visit, so the very first request to a new browser is unprotected. Preload closes that gap by shipping the domain in the browser itself.

Can HSTS cause problems?

Yes, if misconfigured: includeSubDomains with an HTTP-only subdomain breaks it, and a mistake with a long max-age is sticky (browsers honor it until expiry). That’s why the rollout order — short first, then long — exists.