Increase HSTS max-age to meet preload list requirements

What's happening

An HSTS header with a short max-age tells the browser to enforce HTTPS only for a brief window. After max-age elapses, the protection lapses and the next request can be intercepted by an SSL-stripping attacker again. A max-age of 60 or 3600 seconds is essentially the same security posture as not having HSTS at all.

Browsers refresh the HSTS expiry on every successful HTTPS response, so for a daily-active user a 24-hour max-age might be fine, but for a once-a-month visitor it is useless. The HSTS preload list explicitly requires a max-age of at least 31536000 (1 year) to be eligible, with 63072000 (2 years) as the recommended value.

The fix is to raise max-age to a value measured in years, not seconds. There is no downside to a long max-age once you have validated your HTTPS configuration is stable across all subdomains in scope.

Why it matters

Returning visitors who have not loaded the site recently are still exposed to SSL stripping. The window of vulnerability scales with the frequency of visits and the value of the max-age.

The hostname cannot be added to the HSTS preload list, which means brand-new visitors and users in private browsing mode never get HSTS protection on the first request.

SecurityHeaders.com, Mozilla Observatory, and SSL Labs all penalize sub-1-year HSTS values in their grading. PCI scanners will sometimes flag a max-age below 6 months.

Common causes

• Header was set with max-age=60 during a test rollout and never increased.
• max-age=2592000 (30 days) was copied from a 2016 blog post.
• Cloudflare HSTS slider was left at its lowest setting.
• Caddy automatic HTTPS sets a shorter max-age by default if the hostname is not in production mode.
• Multiple servers behind a load balancer disagree on max-age and the lowest wins.

Detect this on your site

Run a quick scan with the Full Site Audit. The tool surfaces this exact issue with the records and context needed to apply the fix below.

How to fix it

1. 1

   Read the current value

   Run curl -sI https://example.com | grep -i strict-transport-security. Note the max-age. Anything below 31536000 (one year, 60×60×24×365) is too short. The value must be in seconds and not include units like 'd' or 'h'.

2. 2

   Raise to 63072000 in your origin config

   In nginx: add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;. In Apache: Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload". Reload the server.

3. 3

   Update CDN if it overrides origin

   Cloudflare and Fastly may rewrite the header. In Cloudflare, set the slider to 1 year minimum (12 months); the dashboard shows the chosen seconds. In Fastly, edit the VCL response handler to set the explicit value rather than letting the origin pass through.

4. 4

   Test with curl across hostnames

   Verify the new value appears on every hostname you control: curl -sI https://example.com | grep -i strict-transport-security and the same for www and any subdomains. The values should match exactly across listeners.

5. 5

   Confirm dynamic HSTS in browsers

   Open chrome://net-internals/#hsts and query the hostname. The 'dynamic_sts_observed' value should be the new max-age. The expiration date in the report should be roughly two years from now.

6. 6

   Submit to the preload list once stable

   After 1 to 2 weeks of running the long max-age cleanly, submit the apex domain at hstspreload.org. Make sure includeSubDomains is set and you have a valid HTTPS cert on every subdomain or the submission will be rejected.

Example

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Header value that meets preload-list requirements

Related fixes