Skip to content

HSTS max-age is too short for browser preload

The max-age value in an HSTS (HTTP Strict Transport Security) header tells a visitor's browser how long to remember that it must always use a secure HTTPS connection to this site. This check looks at that value. On this site, HSTS is present, but the max-age is shorter than the one-year, 31,536,000 second, baseline browsers expect before they'll consider adding the domain to their built-in preload list. A short max-age leaves a re-attack window: once the browser's cached HSTS instruction expires, the very next visit can potentially be downgraded to an insecure connection before the header is refreshed. It also blocks the site from qualifying for the browser preload list at all, since that list requires the one-year minimum. Your developer should bump the max-age value to 31536000 seconds, one year, in the HSTS header configuration. This is required before the domain can be submitted to hstspreload.org, and there's no real downside to setting it once the site is confidently running on HTTPS everywhere. About 10 minutes of configuration.

Why this matters

A short max-age leaves a re-attack window: once the browser's cached HSTS instruction expires, the very next visit can potentially be downgraded to an insecure connection before the header is refreshed. It also blocks the site from qualifying for the browser preload list at all, since that list requires the one-year minimum.

How to fix it

Your developer should bump the max-age value to 31536000 seconds, one year, in the HSTS header configuration. This is required before the domain can be submitted to hstspreload.org, and there's no real downside to setting it once the site is confidently running on HTTPS everywhere. About 10 minutes of configuration.