Your site runs on HTTPS. You bought the certificate, you set up the redirect, the padlock shows. So the traffic is encrypted and you can stop thinking about it, right? Almost. There is one connection that slips through the gap, and it happens before any encryption is on the table.
Picture someone typing yourbank.com into the address bar. They do not type https://, nobody does. So the browser's first move is a plain HTTP request on port 80. Your server answers with a 301 redirect over to https://, and from there everything is fine. But that first request and that redirect travel in the clear. On an open coffee-shop Wi-Fi, an attacker sitting on the same network can intercept it, hold onto the redirect, talk to your real site over HTTPS themselves, and hand the victim a plain HTTP version of the page. This is SSL stripping — tools like sslstrip automate the whole thing. The visitor sees a page that works. Their password and session cookie go straight to the attacker in plaintext.
HSTS (HTTP Strict Transport Security, defined in RFC 6797) is the fix for that specific gap. If you want to know whether a domain has it switched on and configured sensibly, the HSTS check reads the header the server sends and tells you what it actually says.
What the header tells the browser
HSTS is a single response header. It is the server telling the browser: this site is HTTPS-only, so never try plain HTTP again, and rewrite any http:// link to https:// before a single packet leaves the machine. On the first successful HTTPS visit the server sends something like:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
The browser writes the domain into its HSTS memory and changes its own behaviour from then on. Two things happen. Every http:// request to that domain gets rewritten to https:// internally, so the vulnerable port-80 hop never occurs. And if the certificate is ever bad — expired, wrong hostname, self-signed — the browser drops the "proceed anyway" link entirely. The user cannot click through. That is the part that shuts down an active man-in-the-middle rather than just a passive listener.
The three directives, and what each one costs you
The header carries up to three directives, and it is worth knowing exactly what each does before you paste one into production.
| Directive | Required? | What it does |
|---|---|---|
max-age=<seconds> |
Yes | How long the browser remembers the site is HTTPS-only. The timer resets on every visit. |
includeSubDomains |
Recommended | Applies the policy to every subdomain — blog., mail., dev., all of them. |
preload |
Optional | Signals your consent to be baked into the browsers' preload list (more on that below). |
max-age is the one number that matters most. A short value like 300 (five minutes) is fine while you are testing. For anything real — and definitely for preload — you want 31536000, which is one year. Because the clock resets on each visit, regular visitors effectively never fall out of the policy.
includeSubDomains is the directive people underestimate. Without it, an attacker does not bother with your main domain; they go after some forgotten subdomain that still answers on HTTP, and if it shares cookies with the parent, that is the way in. Extending the policy across every subdomain shuts that door. The flip side: turn it on while an internal host like dev.yourdomain.com still runs on plain HTTP and that host will instantly stop loading. So audit your subdomains before you commit.
preload is a bigger commitment than the other two, and it deserves its own section.
The first-visit problem, and the preload list
Plain HSTS has a blind spot. The browser only learns your policy after it has seen the header once — which means the very first visit, before any header has arrived, is still exposed to the same stripping attack. Security people call this Trust On First Use, and it is the one thing the header alone cannot solve.
The HSTS preload list closes it. This is a list of HTTPS-only domains compiled by Google and shipped inside Chrome, Firefox, Safari and the rest. If your domain is on it, browsers know it is HTTPS-only before the user has ever connected, so there is no first request to strip.
Getting on the list means meeting a fixed set of criteria. Treat these as background — the checklist you are aiming at, not something any single header read can fully confirm:
- A valid certificate served on the root domain.
- Every HTTP request on port 80 redirected to HTTPS on the same host.
- The HSTS header served over HTTPS on the base domain with
max-ageof at least31536000, plus bothincludeSubDomainsandpreload. - All of your subdomains reachable over HTTPS.
That second point — the port-80 redirect — is a genuine prerequisite, but it is a separate thing to test from the header itself. The HTTP/HTTPS check is the tool that actually exercises that redirect: it hits your site on plain HTTP and confirms the 301 to https:// is really there. Run it alongside the header check when you are working toward preload.
What the ServerRecords check does, and where it stops
The HSTS check makes an HTTPS request to your domain and reads the Strict-Transport-Security header off the response. It parses the three directives, tells you the max-age in something human (days and years, not raw seconds), notes whether includeSubDomains and preload are present, and flags a max-age that sits below the roughly one-year baseline.
Be clear about the edges, because HSTS has more moving parts than one header read can cover. The tool does not test the port-80-to-443 redirect — that is what the HTTP/HTTPS check is for, and it is the one to reach for there. It also does not query the browser preload list to confirm your submission status or full eligibility; it can see the preload flag in your header, but presence of the flag is not the same as being accepted onto the list. So use this check as a fast, honest answer to one question — is the header there, and are its directives sane — and treat the redirect and the preload criteria as the wider picture to verify separately.
Where to go from here
If HSTS is one item on a longer list, the Domain Health Check folds it in with the rest of a domain's posture so you can see it in context rather than in isolation.
A practical order: get HTTPS solid and the redirect confirmed first, publish the header with a short max-age while you check nothing breaks, then raise it to a year and add includeSubDomains once you have accounted for every subdomain. Only reach for preload when all of that is stable — because getting off the list is far slower than getting on it.