Add the Strict-Transport-Security (HSTS) header

Why it matters

Without HSTS, a browser that is sent to the http:// address first can be intercepted before it reaches the secure site. The header tells browsers to use HTTPS only, for as long as you specify.

Staged change. Do this in stages and check each one before the next, so a mistake does not break your site or your mail.

The fix

1. Before you start, make sure the whole site works over HTTPS, http:// redirects to https://, there is no mixed content, and the certificate renews automatically. Browsers will refuse the plain-HTTP version for the whole max-age period.
2. Stage 1, send the header with a short life of five minutes on HTTPS responses only and check the site over HTTPS. Browsers ignore the header when it arrives over plain http://, so do not add it to the http:// listener.
3. Stage 2, raise max-age to one day (86400) and watch for a day for problems on pages and for the apps and tools that use the site.
4. Stage 3, raise it to 30 days (2592000), then to one year (31536000). One year is the usual target.
5. Do not add includeSubDomains or preload yet. They each have their own finding and need their own checks, and preload is very hard to undo.
6. If something breaks, send max-age=0 over HTTPS. Visitors who already stored a longer value stay locked in until it runs out, which is why you start short.
7. Check the header with curl -sI.

Strict-Transport-Security: max-age=300

Read the documentation ↗(opens in a new tab)

Related

• Reported by the HSTS check
• Fix the malformed Strict-Transport-Security header
• Re-enable HSTS (max-age is zero)
• Raise the HSTS max-age
• Decide whether to add includeSubDomains
• Meet the HSTS preload requirements or remove preload
• Consider submitting the domain to the HSTS preload list