Defaults.Exposed

Defaults.Exposed › Reports

What Is HSTS? The Header 79.9% of Sites Still Skip

Published

HTTP Strict Transport Security (HSTS) is a single response header that tells a browser to talk to your domain over HTTPS only — never plain HTTP — for a fixed period, even if a visitor types http://, follows an old bookmark, or clicks an insecure link. It closes a gap that an HTTP-to-HTTPS redirect cannot: the brief instant on the very first request, before any encryption exists, when an attacker sitting on the network can intercept the connection and quietly keep the user on plain HTTP. HSTS is defined in RFC 6797, it costs nothing, and it is one line of configuration. Yet the August 2026 defaults.exposed census measured HSTS across 231,991,983 TLS-evaluable domains and found that only 20.1% — 46,539,716 — send the header at all. The other 79.9% leave that first request exposed. And of the whole evaluated web, just 2.57% are configured to the standard that removes the gap entirely: preload. This guide explains what HSTS is, how each part of the header works, why HTTPS on its own is not enough, and how to turn it on without locking yourself out.

If your site already redirects HTTP to HTTPS, it is tempting to treat the padlock as the finish line. It is not. A redirect protects the second request onward; HSTS is what protects the first one — and the first one is the only request an attacker on the wire actually needs. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

What Is HSTS?

HSTS — HTTP Strict Transport Security, RFC 6797 — is an instruction a website sends to a browser, carried in an HTTP response header, that says: for the next N seconds, only ever connect to me over HTTPS, and refuse to connect any other way. Once a browser has seen that header from your domain, it stops making plain-HTTP requests to you entirely. If a user types http://yourbusiness.com, the browser rewrites the request to https:// before a single packet leaves the device. There is no plaintext request for anyone to intercept.

The header looks like this:

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

Three things make HSTS matter. First, it is enforced by the browser, not the server — so it protects the connection before the server is ever reached. Second, it is remembered: the browser caches the instruction for the full max-age window, so the protection persists across visits. Third, it is strict — an HSTS-pinned domain that presents an invalid or self-signed certificate produces a hard error the user cannot click through, removing the “proceed anyway” escape hatch that attackers rely on.

Crucially, a browser only honours the HSTS header when it arrives over HTTPS. A header sent over plain HTTP is ignored by design, because an attacker who can strip your encryption could also strip or forge the header. That single rule is the reason HSTS has a “first request” problem — and the reason preload exists.

How the HSTS Header Works: max-age, includeSubDomains, preload

HSTS is configured entirely through the directives inside the one header. There are only three that matter, and each does a distinct job.

max-age=<seconds> — the required directive. It sets how long, in seconds, the browser must remember to use HTTPS only for this domain. Every visit refreshes the clock, so an active site keeps the policy alive indefinitely. Common values:

A short max-age — a few hours or days — weakens the protection, because a user who has not visited recently falls back to being unprotected on their next first request. The header is only as strong as the window it sets.

includeSubDomains — an optional flag that extends the HTTPS-only rule to every subdomain of the domain that sent it: mail., app., billing., and any host that does not yet exist. This is powerful and unforgiving in equal measure. It shuts every subdomain door at once, but if a single subdomain still serves anything over plain HTTP — a legacy status page, an internal tool, an IoT device — that service becomes unreachable the moment the flag propagates. It must be true before you set it, not aspirational.

preload — an optional flag that signals your intent to be added to the HSTS preload list, a roster of domains hard-coded into browsers so they enforce HTTPS-only from the very first request, before ever visiting you. The flag alone does nothing; you must also submit the domain to the list. Preload is the only mechanism that fully closes the first-request gap, and it is where the census sees the sharpest drop-off.

For the exact rule defaults.exposed applies when grading this header across the internet, see the HSTS header methodology.

HSTS vs HTTPS: Why an HTTP-to-HTTPS Redirect Is Not Enough

The most common misconception is that a site which redirects all HTTP traffic to HTTPS is already fully protected. It is not, and the reason is worth understanding precisely, because it is the entire case for HSTS.

Consider what happens when a user types yourbusiness.com — no scheme — into the address bar. The browser’s default is to try http:// first. Your server answers that plain-HTTP request with a 301 redirect to the https:// version. The browser follows it, the encrypted connection is established, and the padlock appears. From the user’s point of view, nothing was wrong.

But look at the sequence. That first request — and the redirect that answered it — travelled in plaintext. An attacker positioned on the network path (a hostile Wi-Fi hotspot, a compromised router, a rogue access point) can intercept that first plaintext request and simply not deliver your redirect. Instead they proxy the site to the victim over HTTP while talking to you over HTTPS, reading and altering everything in between. This is an SSL-strip (or SSL-stripping) attack, and the redirect is powerless against it, because the attack happens before the redirect is ever seen.

HSTS removes the plaintext first request altogether. Once the browser has recorded your HSTS policy, it never sends the initial http:// request in the first place — it upgrades to HTTPS internally, before anything hits the network. There is no plaintext redirect to hijack, because there is no plaintext request. The redirect handles users who arrive over HTTP; HSTS ensures they stop arriving over HTTP at all.

This is why the two controls are complements, not alternatives. You need the HTTP-to-HTTPS redirect so that a browser which has never seen your HSTS header still lands on HTTPS — and you need HSTS so that, from then on, the browser refuses to try HTTP again. The redirect is measured separately in the last mile of HTTPS: why 27 million domains respond to HTTP but never redirect, and the grading rule sits in the HTTP-to-HTTPS redirect methodology. If HTTPS itself is unfamiliar ground, start with what is HTTPS: how the secure web actually works and HTTP vs HTTPS: what’s the difference, and is HTTP safe.

The Census Reality: 79.9% of Sites Skip HSTS

Measure HSTS across the whole TLS-capable web and the picture is stark. Of the 231,991,983 domains the August 2026 census could evaluate for transport security, only 46,539,716 — 20.1% — send an HSTS header at all. The remaining 79.9%, more than 185 million domains, ship no HSTS. Every one of them leaves the first request open to the SSL-strip downgrade described above, no matter how good their certificate or how clean their redirect.

This is not a fringe omission. A domain can score well on the visible parts of HTTPS — a valid certificate, a modern TLS version, a working redirect — and still send no HSTS. The header is invisible to a casual visitor; the padlock shows regardless. That invisibility is exactly why it is skipped: nothing in the browser UI complains about its absence, so it never reaches the to-do list. The census exists to make the invisible measurable.

Check your domain free at defaults.exposed — it reads your live response headers and tells you in about 30 seconds whether HSTS is present, how long its max-age runs, whether it covers subdomains, and whether it is preload-ready. No account needed.

HSTS also sits alongside a wider family of security headers that the census finds are just as widely skipped — Content-Security-Policy, Referrer-Policy, the cross-origin isolation set. The full picture of how these headers cluster is in HTTP security headers: the complete checklist. For the numbers behind HSTS specifically — and how the header divides a “half-locked door” web — see the twin report, HSTS adoption 2026: the half-locked door.

HSTS Preload: The 2.57% That Go All the Way

HSTS as described so far has one residual weakness: the first ever visit. Before a browser has seen your HSTS header even once, it has no record of your policy, so that very first request can still go out over plain HTTP and be stripped. HSTS protects every subsequent visit, but it cannot protect a browser it has never met. This is called the trust-on-first-use gap.

Preload closes it. The HSTS preload list is a set of domains compiled directly into the source code of Chrome, Firefox, Safari, Edge, and every Chromium-based browser. A browser treats a preloaded domain as HTTPS-only from the moment it is installed — before the first request, before any header is ever received. There is no plaintext first request to strip, ever, on any device, because the rule ships inside the browser itself.

Getting onto the list has firm requirements, enforced at hstspreload.org:

  1. Serve a valid certificate on the domain.
  2. Redirect all HTTP to HTTPS on the same host.
  3. Serve HTTPS on every subdomain, including the bare domain and www.
  4. Send an HSTS header on the base domain with max-age of at least 31536000 (one year), the includeSubDomains directive, and the preload directive.

The census finds that clearing this bar is rare. Just 2.57% of all evaluated domains are HSTS-preload-ready — which is only 12.8% of the minority that set the header at all. Put plainly: four out of five domains send no HSTS; of the one in five that do, seven in eight stop short of the configuration that would eliminate the first-request gap for good. Preload is the difference between “protected after I have visited once” and “protected from the very first byte,” and the web has overwhelmingly settled for the former.

How to Enable HSTS Safely (and the Rollback Trap)

HSTS is a single header, but it is one of the few web-security controls that can genuinely lock users out if rushed — because the whole point of the header is that browsers obey it even after you wish they would not. The safe path is a ramp, not a switch.

1. Confirm HTTPS is solid everywhere first. Every page, asset, and subdomain you intend to cover must already work over HTTPS with a valid certificate. HSTS does not fix broken HTTPS; it makes broken HTTPS unreachable. Verify the certificate is valid and current — the census still finds 5.2 million domains serving expired certificates, exactly the state HSTS turns into a hard, un-clickable error.

2. Start with a short max-age and no includeSubDomains. Ship Strict-Transport-Security: max-age=300 — five minutes. If something breaks, the blast radius is tiny and self-heals almost immediately. Watch your traffic and error rates.

3. Ramp the max-age up. Move to a day, then a week, then the full year (31536000) once you are confident. Only now consider includeSubDomains, and only after auditing that every subdomain — current and legacy — serves HTTPS. This flag is the single most common cause of an HSTS outage.

4. Add preload and submit last. Preload is a one-way door you should walk through deliberately. Add the preload directive and submit at hstspreload.org only when the year-long, subdomain-inclusive policy has run cleanly for a while.

The rollback trap. Because browsers cache HSTS for the full max-age, you cannot undo it by simply removing the header — clients that already saw it will keep forcing HTTPS until their timer expires, up to a year later. To back out cleanly you must first serve max-age=0 (which tells browsers to forget the policy) and keep serving it long enough for your visitors to receive it, then remove the header. Preloaded domains are harder still: removal from the browser list is a separate request at hstspreload.org and can take many months to reach users through browser release cycles. The rule of thumb is simple — never enable HSTS on infrastructure you might need to serve over plain HTTP again.

What This Means

For business owners, HSTS is a free control that closes a real, exploited attack — the coffee-shop-Wi-Fi downgrade that strips your customers’ connections back to plaintext on their first click. Your site can have a perfect padlock and still be missing it, because the header is invisible in the browser. At 20.1% adoption across the web, most sites are in exactly that position. Turning it on is a one-line configuration change your host or developer can make in minutes, and the free check tells you in seconds whether it is already there.

For developers and IT teams, HSTS is where “we have HTTPS” and “we are protected against downgrade” stop being the same statement. The work is not the header — it is the discipline around it: confirm HTTPS everywhere before includeSubDomains, ramp max-age rather than jumping to a year, and treat preload as the deliberate, hard-to-reverse commitment it is. The census shows the common failure is not misconfiguration but simple absence: 79.9% of evaluated domains never send the header, and 87% of those that do never reach preload-ready. Both gaps are closed by configuration, not spend.

FAQ

What is HSTS and how does it work? HSTS (HTTP Strict Transport Security, RFC 6797) is a response header — Strict-Transport-Security: max-age=31536000 — that instructs a browser to connect to your domain over HTTPS only, for the number of seconds set in max-age. Once a browser has seen it, it upgrades every future http:// request to https:// internally, before any packet leaves the device, so there is no plaintext request for an attacker to intercept. The header is only honoured when received over HTTPS. In the August 2026 census, only 20.1% of 231,991,983 evaluated domains — 46,539,716 — sent it.

Is HSTS the same as HTTPS? No. HTTPS is the encrypted transport itself — the certificate, the TLS handshake, the padlock. HSTS is a policy layered on top of HTTPS that forces the browser to use HTTPS and refuse plain HTTP. You can have HTTPS without HSTS, and most of the web does: a valid certificate and a working redirect still leave the very first request able to travel in plaintext and be stripped. HSTS is what removes that first-request exposure. Think of HTTPS as the lock and HSTS as the rule that says the door must always be locked.

What is HSTS preload? Preload is a list of domains compiled directly into browsers, so they enforce HTTPS-only for those domains from the first request — before the browser has ever received your HSTS header. It closes the trust-on-first-use gap that ordinary HSTS leaves open on a device’s initial visit. To qualify you must serve a valid certificate, redirect all HTTP to HTTPS, serve HTTPS on every subdomain, and send max-age of at least one year with includeSubDomains and preload, then submit at hstspreload.org. The census found only 2.57% of evaluated domains meet this bar — 12.8% of those that set HSTS at all.

Do I need HSTS if I already have HTTPS? Yes. HTTPS and an HTTP-to-HTTPS redirect protect the second request onward, but the first request — the one a user makes before your redirect is seen — still goes out in plaintext and can be intercepted in an SSL-strip attack. HSTS is the only control that stops the browser from ever making that plaintext first request again. You can confirm whether your domain already sends it in about 30 seconds: Check your domain free at defaults.exposed, which reads your live headers and reports HSTS presence, max-age, subdomain coverage, and preload readiness.

Will enabling HSTS break my website? It can, if rushed — which is why you ramp it. HSTS makes broken or missing HTTPS unreachable rather than merely warned about, so any subdomain still on plain HTTP goes dark the moment includeSubDomains propagates. Enable it in stages: confirm HTTPS works everywhere, start with a short max-age such as 300 seconds, increase gradually to a year, and add includeSubDomains only after auditing every subdomain. Done in order, HSTS breaks nothing. Done as a single jump straight to a one-year, subdomain-inclusive, preloaded policy, it can lock users out for months.

How do I turn HSTS off if I need to? Carefully, because browsers obey the policy for the full max-age even after you remove the header. To back out, first serve max-age=0, which tells browsers to forget the policy, and keep serving it long enough for your visitors to receive it — then remove the header. Simply deleting the header does nothing for clients that already cached it. If the domain is on the preload list, you must additionally submit a removal request at hstspreload.org, and propagation through browser releases can take many months. This is why HSTS should only cover infrastructure you are certain will stay on HTTPS.

Data to cite

See where your own domain stands

HSTS is invisible in the browser: the padlock shows whether or not the header is set, so a domain can look fully secure and still leave its visitors’ first request open to a downgrade. The only way to know is to read the response headers directly — which is exactly what the free check does.

Check your domain free at defaults.exposed — it reads your live HTTP response headers straight from your server and tells you instantly whether HSTS is present, how long its max-age runs, whether includeSubDomains is set, and whether the domain is preload-ready. It takes about 30 seconds and needs no account. If the check flags a missing or half-configured header and you want it set up properly — the right max-age, subdomains audited, preload done deliberately — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Related from this series: HSTS Adoption 2026: The Half-Locked Door · The Last Mile of HTTPS: 27 Million Domains That Never Redirect · What Is HTTPS: How the Secure Web Actually Works · HTTP Security Headers: The Complete Checklist

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned; 231,991,983 evaluated for transport security. All figures are counts of evaluated domains. References: RFC 6797 (HSTS), RFC 2818 (HTTP over TLS).

How to cite this report

Press / blog: defaults.exposed (2026). What Is HSTS? The Header 79.9% of Sites Still Skip. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/what-is-hsts-the-header-79-9-of-sites-still-skip

Academic: defaults.exposed. (2026, August 21). What Is HSTS? The Header 79.9% of Sites Still Skip. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/what-is-hsts-the-header-79-9-of-sites-still-skip

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=231,991,983 evaluated domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded them using methodology v9, evaluating 231,991,983 of them for transport-layer security including HSTS. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →