What Is HSTS?

At a glance

Strict-Transport-Security reduces opportunities to downgrade a user to unencrypted HTTP.

How HSTS prevents downgrade to HTTP

HSTS is enabled by a Strict-Transport-Security header received over HTTPS. Once the browser remembers the policy, it locally upgrades HTTP requests to HTTPS during the policy lifetime and prevents easy bypass of certificate errors. This reduces downgrade and SSL-stripping risks after the policy has been learned.

A browser should accept HSTS only over validated HTTPS, not untrusted plaintext HTTP. A first-time visitor may still begin with HTTP. A preload list can distribute the policy with browsers beforehand, but enrollment requires stricter HTTPS coverage.

max-age, includeSubDomains and preload

• max-age is the number of seconds a browser remembers the policy. A value of zero requests removal, but offline clients or those that do not return will not immediately receive it.
• includeSubDomains extends coverage to every subdomain, including old systems and currently unused names. Inventory the full domain estate before enabling it.
• Preloading is a browser-maintained mechanism, not an ordinary RFC directive that enrolls a site automatically. Submission, removal and browser-version propagation take time.
• Only an HTTPS response can establish the trusted policy. An HTTP redirect header cannot do so; CDN and origin configurations should avoid contradictory values.

Why deployments should begin with a short lifetime

A subdomain without a valid certificate, or an old service with limited HTTPS support, may become unreachable under long-lived includeSubDomains. A careful rollout establishes HTTPS and automatic renewal first, observes a short max-age, then extends the lifetime and evaluates subdomain coverage and preload.

Domain migrations, service retirement and certificate-platform changes still need working HTTPS until relevant clients' policies expire. HSTS does not fix bad certificates: it prevents users from casually ignoring their errors, making reliable certificate monitoring essential.

Practical use and interpretation

Presence, max-age, subdomain coverage and the preload directive are directly observable. A long lifetime may suggest mature deployment, but verifying complete coverage requires checking the affected hosts and certificates, not merely the homepage header.

If the header is absent, check whether the final response used HTTPS and whether nodes or pages differ. A confirmed absence means that response did not deliver HSTS; it does not mean HTTPS itself is invalid.

Points to consider

HSTS reinforces HTTPS usage, but all covered subdomains must support reliable HTTPS before broad deployment.

Frequently asked questions

Can HSTS replace HTTP-to-HTTPS redirects?

Not completely. First-time visitors and clients without HSTS still need server redirects. HSTS adds local enforcement for supporting clients.

Is includeSubDomains always better?

It provides wider coverage but requires all current and future subdomains to support dependable HTTPS. An incomplete inventory can lead to service outages.

Does max-age=0 instantly clear HSTS for everyone?

No. Offline or non-returning clients do not receive the change immediately. Preload removal requires a separate process and browser propagation.