Glossary Infrastructure
HSTS preload
Also: HTTP Strict Transport Security preload, HSTS preload list
Origin: RFC 6797 (HTTP Strict Transport Security, 2012); the Chromium preload list dates to 2012 and is canonical, consumed by Firefox, Safari, and Edge.
A browser-vendor-maintained list of domains for which the browser refuses to make any plaintext HTTP request, regardless of whether the user has previously visited the domain — eliminating the bootstrap attack against the HSTS response header. Maintained by Chromium and consumed by all major browsers.
Reviewed
HSTS preload is a browser-vendor-maintained list of domains for which the browser refuses to make any plaintext HTTP request, regardless of whether the user has previously visited the domain. The list addresses the bootstrap attack against the HTTP Strict Transport Security header: an HSTS response header instructs the browser to upgrade subsequent connections to HTTPS, but the first connection a user makes to a new domain — before any HSTS header has been received — may still be plaintext, and an active network attacker who controls that first connection can prevent the upgrade from ever happening. Preloading puts the domain on the list before any first connection, eliminating the bootstrap window.
The mechanic is simple. A domain owner publishes a strict HSTS header with a long max-age (minimum 31536000 — one year — under the canonical inclusion policy), with includeSubDomains, and with preload. The owner then submits the domain to the Chromium HSTS preload list at hstspreload.org. After Chromium accepts the submission and a subsequent Chromium release ships, every browser that consumes the Chromium list (Firefox, Safari, Edge, mainline Chromium) will refuse plaintext connections to the domain.
The operational caveat is that removal is slow. A domain that is preloaded and then withdraws its HSTS header cannot un-preload by reversing the header — the list is consumed at browser-build time, not dynamically, and a removal request goes through a separate process at hstspreload.org that ships over weeks-to-months as Chromium releases roll out. This makes preloading a one-way decision in practice: a domain owner should be confident in their HTTPS-only posture before submitting.
For an offshore-hosting operator, HSTS preload is a baseline-hygiene step: the publication’s primary domain and the operator’s billing surface should both be on the list, with subdomain-wildcard inclusion. The status can be checked at hstspreload.org, and the publication will host a sober checker on the upcoming /tools surface so an editor can verify the brand’s own status without leaving the publication’s domain.