Security
HSTS rollout planning: enable strict HTTPS without locking in a mistake
HSTS tells browsers to use HTTPS for a hostname for a period of time. That persistence is why rollout should happen after HTTPS is stable on every covered name. An HSTS error cannot be bypassed by simply asking users to click through a certificate warning.
Stabilize HTTPS and redirects first
Verify valid certificates, complete chains, canonical HTTPS redirects, and renewal automation on the exact host that will send HSTS. Fix mixed HTTP dependencies that users still need.
Do not add HSTS to compensate for an HTTPS setup that is not reliable.
Start with a short max-age
A small max-age limits the blast radius while you confirm real browsers and operational renewal. Increase gradually once you are confident the host will remain HTTPS-only.
Remember browsers that already received the header retain it until their stored max-age expires.
Treat includeSubDomains as a separate commitment
With includeSubDomains, every covered subdomain must support valid HTTPS, including forgotten internal/public services and delegated customer/application names under that hierarchy.
Inventory DNS and certificate ownership before enabling it.
Consider preload only after long-term readiness
Browser preload has stricter requirements and removal can take time. Review the current preload program requirements before publishing preload headers. Document who owns certificate renewal for every included hostname before making that commitment.
- Make HTTPS reliable first.
- Increase max-age gradually.
- Audit every subdomain before includeSubDomains.
- Treat preload as a separate commitment.