HSTS Preload Strategy
HSTS preload embeds the domain in a browser-shipped list so the first visit uses HTTPS without a redirect, eliminating the downgrade window the initial plain HTTP request exposes.
Definition
HSTS preload strategy is the practice of sending the Strict-Transport-Security header with the preload directive and submitting the domain to the browser preload list, so that every first visit — including the one that would otherwise be plain HTTP and vulnerable to downgrade — goes directly to HTTPS.
Context and scope
Applied in high-security web properties where the cost of a first-visit SSL strip attack justifies the operational commitment of being on the browser list.
Common misconceptions
- HSTS alone prevents downgrade — it prevents downgrade after the first visit; the first plain HTTP visit is still vulnerable, which preload closes
- Preloading is permanent — it is removable but the removal takes months to propagate; preloading a domain you might need to serve over HTTP is a commitment
Anti-patterns
- Preloading a subdomain that hosts a plain HTTP service, breaking that service for every browser user
- Sending HSTS without includeSubDomains when the apex and www both need it, leaving www vulnerable to downgrade
Related concepts
Authoritative source
What it is
HSTS preload strategy is the practice of sending the Strict-Transport-Security header with the preload directive and submitting the domain to the browser preload list, so that every first visit — including the one that would otherwise be plain HTTP and vulnerable to downgrade — goes directly to HTTPS. Applied in high-security web properties where the cost of a first-visit SSL strip attack justifies the operational commitment of being on the browser list. The protocol’s semantics — safe versus unsafe, idempotent versus non-idempotent, cacheable versus non-cacheable — are contracts the client and intermediary rely on, and violating them breaks the web.
How it works
Headers carry the negotiation: content type, encoding, caching directives, and conditional request validators together let a client and server reach the cheapest correct response. Connection reuse eliminates handshake overhead; multiplexing removes head-of-line blocking; streaming avoids buffering the entire body. Each feature has a failure mode — keep-alive on a broken proxy, multiplexing with a misbehaving server — that must be detected and handled.
When to apply and pitfalls
Apply whenever a client and server communicate across a trust boundary the protocol already spans. The pitfall is treating HTTP as a transport and ignoring its semantics — POSTing a retrieval, marking a mutating request cacheable, or omitting the validator that would enable a 304. Intermediaries — CDNs, proxies — implement the standard literally, so semantic violations produce surprising behavior far from the origin.