What's the safest HSTS configuration?

hsts-configuration-weakglobal

The safest HSTS configuration uses max-age=63072000 (two years), includeSubDomains when all subdomains support HTTPS, and preload for sites committed to permanent HTTPS. This configuration provides maximum protection against protocol downgrade attacks and ensures browsers never attempt HTTP connections. Lower max-age values reduce commitment but leave larger windows for attack. Omitting includeSubDomains or preload creates subdomain and first-visit vulnerabilities.

What’s wrong

The Strict-Transport-Security header is missing, uses a short max-age value below recommended thresholds, or omits includeSubDomains when subdomains exist. Short max-age values expire quickly, allowing HTTP connections after expiry. Missing includeSubDomains leaves subdomains vulnerable to downgrade attacks. No preload directive prevents first-visit protection. The configuration provides partial HSTS coverage with security gaps.

Why it matters

HSTS protects against protocol downgrade attacks where attackers force browsers to use HTTP. An attacker intercepting the connection can strip HTTPS from links and redirects. Without HSTS, browsers follow this manipulation. Short max-age values create windows where HSTS expires and attacks become possible again. Subdomains without HSTS enforcement can be exploited to steal cookies set on parent domains. First-visit vulnerability leaves initial connections exposed. Weak HSTS configuration provides the appearance of security without full protection.

The correct change

Set Strict-Transport-Security to max-age=63072000; includeSubDomains; preload for sites with all subdomains on HTTPS. Use max-age=63072000 alone if subdomains cannot support HTTPS yet. The two-year max-age satisfies preload requirements and provides long-term protection. Include the preload directive and submit the domain to hstspreload.org to protect first visits. Verify all subdomains work over HTTPS before adding includeSubDomains. The end state is a header that maximizes protection duration and coverage.

Scope

This condition applies globally. HSTS headers affect the entire hostname and optionally all subdomains. The policy applies after the browser receives the header on any HTTPS response. Each hostname needs its own HSTS header unless covered by a parent domain using includeSubDomains. The scope of includeSubDomains is recursive, affecting all subdomain levels.

How to verify

• Validation confirms the condition is resolved:
• • Strict-Transport-Security header present on all HTTPS responses
• • max-age value is 63072000 seconds or greater
• • includeSubDomains directive present if all subdomains support HTTPS
• • preload directive present if submitting to preload list
• • Browser internal HSTS list shows the domain with correct expiry
• • All subdomains work over HTTPS if includeSubDomains is set
• • Domain appears on hstspreload.org if submitted

Takeaway

• Maximum protection uses max-age=63072000 with includeSubDomains and preload
• Two-year max-age satisfies preload requirements and extends protection duration
• includeSubDomains applies policy to all subdomains recursively
• Preload protects first visits by including domains in browser embedded lists
• All affected subdomains must support HTTPS before enabling includeSubDomains

FAQ

Why specifically 63072000 seconds instead of other values?

63072000 seconds equals two years. The HSTS preload list requires a minimum max-age of two years for submission. Two years balances long-term protection with eventual expiry if HTTPS becomes unsupportable. Shorter values fail preload submission requirements. Longer values work but provide marginal benefit over two years. The two-year standard emerged from preload list requirements.

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.

The fix

Maximize HSTS protection by using longest reasonable max-age and full subdomain coverage

Done when: Strict-Transport-Security header set to max-age=63072000; includeSubDomains; preload with all subdomains supporting HTTPS

Do not

• Do not use max-age values below 31536000 seconds for production sites
• Do not enable includeSubDomains without verifying all subdomains support HTTPS
• Do not add preload directive without understanding permanent commitment
• Do not deploy HSTS without testing HTTPS functionality thoroughly first

How to verify

• HSTS header present with max-age=63072000 or greater
• includeSubDomains directive present when applicable
• preload directive present if submitted to preload list
• All subdomains accessible over HTTPS if includeSubDomains is used
• Browser HSTS state shows correct policy for hostname

Find every page with this

probeo monitors this continuously across every page of your site, and records which pages passed, which failed, and which it could not determine.