HSTS header or the preload list: which one actually protects the first request?

HSTS header or the preload list: which one actually protects the first request?

What is the gap that HSTS (HTTP Strict Transport Security, RFC 6797) cannot close on its own? The trust-on-first-use problem.

A plain Strict-Transport-Security header only takes effect after a browser has seen it once over HTTPS. The very first navigation — or the first after the max-age expires — is still hijackable via an SSL-stripping attacker on the path. The header is necessary but leaves a window.

The preload list (maintained by Chromium, consumed by all major browsers) hardcodes your domain as HTTPS-only into the browser binary, eliminating the first-request gap entirely. To qualify you must serve max-age of at least 31536000 seconds, plus includeSubDomains and the preload token.

The catch is reversibility. Removal from the preload list propagates only with browser releases — months, not minutes. Preload includeSubDomains can also strand a forgotten internal subdomain that lacks a certificate.

— Ship the header everywhere; it is the baseline.
— Preload only after every subdomain genuinely serves HTTPS.
— Treat preload as a near-permanent commitment, not a toggle.

Further reading: RFC 6797; hstspreload.org submission requirements.

Bottom line: the header protects returning visitors; only preload protects the first contact — at the cost of slow, painful reversibility.