How to Fix Missing HSTS
Use this page when the HSTS Checker shows missing or weak Strict-Transport-Security on a public hostname.
What This Means
HSTS should only be added after the site is already stable over HTTPS. The goal is not merely to publish the header. The goal is to make browsers remember HTTPS-only behavior without trapping users behind certificate errors, subdomain surprises, or brittle preload decisions.
| Question | What to verify | Why it matters |
|---|---|---|
| Is HTTPS stable? | Certificates, redirects, and edge behavior | HSTS amplifies existing HTTPS problems if rollout is premature. |
| Are subdomains ready? | Mail, support, preview, or forgotten hostnames | includeSubDomains can break hosts you forgot to inventory. |
| Is max-age appropriate? | Temporary smoke-test versus strong production value | The wrong value can weaken protection or make rollback painful. |
| Is preload warranted? | Long-term operational readiness | Preload is powerful but much slower to reverse. |
Common Causes
Patterns worth checking first
- No HTTPS rollout process: The site is on HTTPS, but no one finalized browser-side enforcement.
- Subdomain uncertainty: Teams avoided HSTS because not every host was reviewed.
- Fear of lock-in: Preload and includeSubDomains felt risky without a staged plan.
How To Confirm It Safely
Confirmation steps
- Confirm the final HTTPS response is healthy and stable on the public hostname.
- Check certificates and redirects on any subdomains that matter to the business.
- Decide whether you are testing, hardening, or pursuing preload readiness.
- Verify that the header is absent or weaker than intended on the live response.
Fix Workflow
- Validate HTTPS operations first. Check certificates, redirect behavior, and important subdomains before adding HSTS.
- Choose the rollout stage. Start with a lower max-age if the environment still needs proof, then raise it once stable.
- Add stronger scope carefully. Only add includeSubDomains or preload after the broader estate is reviewed.
- Retest the live response. Confirm the final HTTPS response now carries the intended HSTS policy.
Implementation Examples
Strong production HSTS header
Strict-Transport-Security: max-age=31536000; includeSubDomainsRollout Risks
HSTS will not fix an unhealthy HTTPS deployment
It assumes HTTPS is already reliable.
- Repair certificate and redirect issues before promotion.
- Do not use HSTS to paper over transport drift.
includeSubDomains is risky if inventory is incomplete
Forgotten hosts are the classic HSTS rollout surprise.
- Inventory mail, support, preview, and legacy hosts.
- Use a staged approach if the estate is still messy.
Validation Checklist
Post-fix validation
- The final HTTPS response includes the intended HSTS header.
- Important subdomains remain healthy if includeSubDomains was used.
- Certificates and redirects stay stable after rollout.
- The HSTS Checker confirms the expected policy strength.
FAQ
Should I add preload right away?
Usually no. Preload is best treated as a later milestone.
- Prove long-lived HTTPS stability first.
- Submit to preload only after sustained confidence.
Can I use HSTS without includeSubDomains?
Yes. It can be a sensible intermediate step when the wider estate is not ready.
- Harden the main hostname first.
- Promote the scope once subdomains are validated.