HSTS: what it protects, and what can break

HSTS (HTTP Strict Transport Security) is a header your server sends with its HTTPS responses. It tells the browser to stop contacting your site over plain HTTP for a period you set. A typed address without "https", an old "http" link: the browser switches them to HTTPS itself before sending anything.

It covers the gap a redirect to HTTPS leaves open, and it commits your whole domain. It is one of the headers our website security audit records, along with its value.

The request a redirect does not protect

Most sites redirect the "http" address to the "https" one. The redirect gets the visitor to the right place, but their first request has already gone out unencrypted. On a shared network, such as public Wi-Fi, whoever controls the network can answer at that moment instead of your server and keep the visitor on an unencrypted version.

RFC 6797, which has defined HSTS since 2012, describes exactly this case: the visitor types the address, or follows a link, using "http". Cookies travel with that first request unless they carry the Secure attribute, covered in the guide to secure cookie attributes.

The header has a second, less known effect. On a site that has sent it, the browser no longer offers to click through a certificate error: the RFC says the user gets no recourse. The page simply does not open.

One gap remains. The browser only learns the rule after receiving the header once over HTTPS, and a header received over plain HTTP is ignored. The very first visit is not covered, unless the domain is preloaded.

max-age, includeSubDomains, preload: what each directive sets

The header fits on one line, and each directive commits you to something different.

max-age sets, in seconds, how long the browser remembers the rule. Every response that carries the header renews it. A value of zero tells the browser to forget the rule, and a few minutes lets a visitor who comes back the next day go out unencrypted again.
includeSubDomains extends the rule to every subdomain: the shop, the blog, the client portal, and the ones nobody remembers.
preload is not defined in the RFC. It signals that the domain agrees to be added to the preload list maintained by the Chromium project, which ships with the browser: the domain is treated as HTTPS-only before the first visit. Firefox, Safari and Edge use lists based on it.

Getting on the list requires a max-age of at least one year, includeSubDomains, and HTTPS on every subdomain.

What breaks, and why backing out is slow

With includeSubDomains, a subdomain still on plain HTTP becomes unreachable for any visitor who has been to your site: an old client portal, an internal tool, a test address, a third-party service mapped to one of your subdomains. The visitor gets an error with no button to continue.

An expired certificate has the same effect on the main domain. Where visitors could once accept the warning and go in, the page no longer opens at all.

Backing out takes time. The browser keeps applying the rule until max-age runs out, and it only sees a shorter value when it comes back to the site. For the preload list, its official site warns that removal takes months to reach users, and asks domains to apply only if they can keep HTTPS on the whole domain and every subdomain for the long term.

France's national cybersecurity agency (ANSSI) sets the same condition. In its recommendations for building a website (in French), HSTS is recommendation R2, with a warning: long-term HTTPS access is a prerequisite, because HSTS makes plain HTTP access impossible.

What we find on the sites we audit

40%send no HSTS header, so their visitors can still arrive through an unencrypted request

This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.

What the audit looks at

The audit reads the header on your site's HTTPS response, as a browser receives it. The report gives the value as served: the max-age, and whether includeSubDomains and preload are present. A missing header takes a fixed number of points off the pillar score.

The redirect from the plain HTTP address is measured separately, because the two do different jobs: the redirect brings the visitor back to HTTPS, HSTS keeps the request from going out unencrypted. A site can have one without the other. A server that does not answer over plain HTTP at all is not penalized, since it serves no page unencrypted.

What is a simple setting, and what needs preparation

When all your subdomains serve HTTPS, the header is a single setting, at your host, in the service in front of your server, or in a CMS extension.

The part that needs preparation is the inventory: every subdomain, including the ones no longer in use or run by a vendor. The careful path is a short max-age first, lengthened once the inventory checks out, and preloading last, only if HTTPS will hold for the long term.

HSTS sits alongside the other protective headers in the guide to HTTP security headers. On the domain side, DNSSEC protects an earlier step: the answer that tells the browser which server to connect to.

What this check doesn't tell you

We read the header your server sends and how the plain HTTP address behaves. We do not simulate an attack, and we do not check whether your domain is on the preload list.

The report lists the subdomains that are publicly visible. Subdomains on an internal network are out of our reach, and checking that they serve HTTPS before you turn on includeSubDomains is on your side.

By Quentin Mathis, Z29K · updated September 28, 2026