EngineeringScoreFix the Strict-Transport-Security max-age
A Strict-Transport-Security header only does its job for as long as its max-age lasts, and only if a browser can actually parse a max-age value out of it. A header with max-age=0 is not a weak policy, it is HSTS being actively switched off: browsers that already trusted the site are told to forget that immediately. A header with no valid max-age at all (missing, or too malformed to parse) is invalid per RFC 6797 and is ignored outright, so it protects nobody despite being present in every response.
Why it matters
A Strict-Transport-Security header only protects repeat visitors for as long as its max-age lasts, and a header with no valid max-age at all is ignored outright by browsers. Either state (expired, deliberately zeroed out mid-rollback, or malformed) leaves every visitor as exposed to a downgrade attack on their next visit as if the header had never been sent, even though it's present in every response.
How to fix
- 1 Inspect the current Strict-Transport-Security header value and confirm it has a max-age directive that actually parses (unquoted or quoted numeric seconds).
- 2 Set max-age to at least 31536000 (one year); 15552000 (six months) is the floor for the policy to reliably protect returning visitors.
- 3 Verify HTTPS is enforced everywhere before enabling includeSubDomains.
- 4 Re-scan and confirm the header now reports as enabled, not weak.
Common mistakes
- Shipping max-age=0 as part of a rollback or migration and leaving it there: it's meant to be a temporary escape hatch, not a resting state, and every day it stays at 0 is a day every returning visitor is downgradable again.
- Assuming a header that appears in the response at all means the site is protected, without checking that max-age actually parsed to a usefully large number.
- Quoting the max-age value (`max-age="31536000"`): legal per RFC 6797 but easy for a hand-rolled parser (including a security scanner) to miss, which can hide a perfectly good policy behind a false "not protected" reading.
How to verify
- 1 Inspect the response headers for Strict-Transport-Security and confirm max-age is a real, parseable number of at least 15552000 (six months), ideally 31536000 (one year).
- 2 Confirm max-age is not 0 unless the site is deliberately and temporarily rolling HSTS back.
- 3 Re-run the scan and confirm the finding now reports HSTS as enabled, not weak.
Related checks
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.