What's the safest HSTS configuration?

hsts-configuration-weak global

The issue

A weak HSTS policy leaves gaps an attacker on the network can use to push visitors back to plain HTTP: a short max-age lapses, a missing includeSubDomains leaves subdomains open, and a missing header protects nothing.

The cause is usually a header set once at a cautious value and never raised.

Scope

The policy applies to the hostname that sends it and, with includeSubDomains, every subdomain. Probeo checks the Strict-Transport-Security header on each response it fetches.

How to check you have it

In probeo: no header is recorded as hsts-missing. A max-age under 31536000 seconds is recorded as hsts:short-max-age, and a policy without includeSubDomains as hsts:no-include-subdomains.
By hand: run curl -sI https://example.com/ and read strict-transport-security.

The fix

Send Strict-Transport-Security: max-age=63072000; includeSubDomains on every HTTPS response.

Two years is a common choice, and anything from one year passes probeo’s check. Add includeSubDomains only once every subdomain serves valid HTTPS. Add preload and submit the domain at hstspreload.org only when HTTPS is permanent.

Done when: every HTTPS response carries a max-age of at least one year with includeSubDomains, and the check above comes back clean.

Do not

Do not use a max-age below 31536000 seconds in production.
Do not add includeSubDomains before every subdomain supports HTTPS.
Do not add preload without accepting that removal is slow.

FAQ

Why specifically 63072000 seconds instead of other values?

63072000 seconds is two years, a common choice. The hard floors are one year: probeo records hsts:short-max-age below 31536000 seconds, and hstspreload.org requires at least 31536000 for submission.

What happens if HTTPS breaks with HSTS active?

The site becomes inaccessible until HTTPS is restored. Browsers refuse HTTP connections and certificate errors prevent HTTPS access. Users cannot bypass these restrictions easily in modern browsers. HSTS is intentionally difficult to override. Test HTTPS thoroughly before deploying HSTS with long max-age values. The risk of lockout makes gradual rollout with short max-age advisable initially.

Should staging and development environments use HSTS?

Use different hostnames for development that are not in production HSTS policy. HSTS applies to hostnames regardless of environment. Setting HSTS on a hostname affects all environments using it. Development environments often use self-signed certificates that conflict with HSTS requirements. Separate hostnames prevent HSTS from affecting development workflows.

Can HSTS be removed or reduced after deployment?

Yes, but gradually. Set max-age=0 to tell browsers to expire HSTS immediately on next visit. Users who do not visit while the removal header is active remain in HSTS enforcement until their previous max-age expires. HSTS preload removal requires submitting a removal request and waiting for browser updates to propagate. Removing HSTS reduces security and should only happen for operational necessity.

Does HSTS affect HTTP-only API endpoints?

HSTS applies to entire hostnames including API paths. An API endpoint at the same hostname as web content inherits HSTS policy. Browsers and HTTPS-aware HTTP clients enforce HSTS. Legacy HTTP-only clients that do not implement HSTS may continue making HTTP requests. Place APIs that must support HTTP on separate hostnames not covered by HSTS.

How does HSTS interact with HTTP to HTTPS redirects?

HSTS eliminates the need for redirects after first visit. The first HTTP request redirects to HTTPS and returns the HSTS header. Subsequent requests go directly to HTTPS without attempting HTTP. The redirect remains necessary for first visits and clients that do not support HSTS. Preload removes the first-visit redirect need by starting with HTTPS.

Which product detects this

Probeo checks this on every page of your site as part of Site Clarity. This page explains one instance; the product tells you every page that has it.