HSTS Checker
Check HTTP Strict Transport Security for any domain. Verify max-age, includeSubDomains, preload flags, and HSTS preload list membership.
What HSTS Does and Why It Exists
HSTS (RFC 6797) exists to kill one specific attack: SSL stripping. A site that redirects HTTP to HTTPS still accepts that first insecure request, and an attacker sitting on the network path — a hostile Wi-Fi hotspot, a compromised router — can intercept it, keep the victim on plain HTTP, and proxy the real HTTPS site behind the scenes while reading everything. Once a browser has seen a Strict-Transport-Security header, that window closes: the browser rewrites every HTTP URL for the domain to HTTPS internally before any request leaves the machine, and certificate errors become hard failures the user cannot click through.
The max-age directive is a countdown in seconds, refreshed every time the browser sees the header again. That persistence is the feature and the risk: a mistake stays cached in visitors' browsers until the timer runs out, and you have no remote kill switch. The safe rollout is incremental — start around max-age=300 while you verify every host, raise it to a day, then a month, and only commit to a year once HTTPS has been boring for a while. Add includeSubDomains only after auditing every subdomain, because it extends the contract to all of them.
Even a perfect header leaves the very first visit unprotected, which is what the preload list solves: domains baked directly into Chrome, Firefox, Safari, and Edge that are HTTPS-only from the first packet. To qualify at hstspreload.org you need max-age=31536000 or higher, includeSubDomains, the preload token, and a working HTTP-to-HTTPS redirect. Understand the trade before submitting: removal requires waiting for updated lists to ship inside browser releases, so escaping the preload list takes months — it is close to a one-way door.
The Directives and Decisions That Matter
max-ageHow long (in seconds) the browser enforces HTTPS-only, refreshed on every response. 31536000 (1 year) is the preload minimum; short values are for testing only.
includeSubDomainsExtends enforcement to every subdomain — including forgotten HTTP-only internal hosts. The most common source of HSTS outages; audit DNS before enabling.
preloadA consent token for the browser-embedded preload list. On its own it does nothing — you must also submit the domain at hstspreload.org and meet the requirements.
Header syntaxnginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; — Apache uses Header always set; Next.js sets it via headers() in next.config.js.
First-visit gapHSTS is trust-on-first-use: the policy arrives in a response, so the very first request is unprotected. Only preloading closes this gap completely.
Rollback strategyServe max-age=0 over valid HTTPS and browsers drop the cached policy on their next visit. Preload rollback is far slower — it waits on browser release cycles.
Frequently Asked Questions
What is HSTS?
HTTP Strict Transport Security tells browsers to only connect via HTTPS for a specified period. Once a browser sees a valid HSTS header, it refuses HTTP connections and auto-upgrades them, protecting against SSL stripping attacks.
What is the HSTS preload list?
Domains hardcoded into browsers (Chrome, Firefox, Safari, Edge) that are always loaded over HTTPS — even on first visit. Submit at hstspreload.org. Requires HTTPS on all subdomains and includeSubDomains + preload flags.
What max-age should I use?
Start with max-age=300 (5 min) to test. Increase to 86400 (1 day), then 2592000 (30 days). For preload eligibility you need at least 31536000 (1 year). Don't set long values until HTTPS is stable.
Is HSTS without preload still useful?
Yes. HSTS protects returning visitors even without preload. The TOFU (Trust On First Use) risk only applies to the very first visit. Preload eliminates even that risk.
Can HSTS brick my site?
It can lock users out temporarily if deployed carelessly. Once a browser caches the header, it refuses plain-HTTP connections to your domain for the full max-age — and with includeSubDomains, to every subdomain too. If any host then loses valid HTTPS (an expired certificate, an HTTP-only internal app), visitors see a hard error they cannot click through, and you cannot remotely clear their cached policy. This is why rollouts should start with a short max-age and grow only once everything serves clean HTTPS.
How do I undo HSTS preloading?
Slowly, and that is by design. You must stop sending the preload token, serve a reduced or zero max-age, and request removal at hstspreload.org — but the change only reaches users when their browser ships an updated preload list, which typically takes months, and users on older browser versions keep the pinned entry indefinitely. Treat preload submission as effectively permanent and only submit once you are certain the domain and all its subdomains will serve HTTPS for the long term.
Does HSTS protect the very first visit?
No. HSTS is trust-on-first-use: the browser only learns the policy from a response header, so the initial plain-HTTP request — before any redirect to HTTPS — is still interceptable by an on-path attacker. The preload list closes this gap by baking your domain into the browser itself, so even a brand-new visitor never sends an unencrypted request.
What subdomain pitfalls should I watch for with includeSubDomains?
includeSubDomains applies the policy to every label under the host that set it — including internal tools, staging hosts, and vendor-managed CNAMEs you may have forgotten about. If intranet.example.com is HTTP-only, it becomes unreachable for anyone whose browser cached the header from example.com. Audit DNS for every subdomain and confirm each serves valid HTTPS before adding the flag, and remember the header must be set on the apex domain to cover the whole tree.