Fix Missing HSTS | Add Strict-Transport-Security Guide
When a scanner reports a missing HSTS header, your HTTPS responses are not sending Strict-Transport-Security. Without it, browsers have no way to remember that your site must load over HTTPS — even if every request redirects from HTTP. An attacker on a shared network can intercept the first HTTP request before the redirect fires, exposing session cookies and credentials. This guide explains what HSTS is, why a missing HSTS header appears as a finding, and how to add the header on Nginx, Apache, or a CDN without creating rollback problems.
What This Means
The Strict-Transport-Security header tells browsers to refuse plain HTTP connections to your hostname for a set period. The key directive is max-age, measured in seconds. A common production value is 31536000 (one year), but starting with a lower value such as 300 seconds lets you verify the deployment without locking users in for long. The includeSubDomains directive extends the policy to every subdomain — powerful, but dangerous if you have forgotten hosts that are not yet on valid HTTPS. The preload directive signals intent to join browser vendor preload lists, which hard-codes HSTS enforcement before any first visit; this is permanent and slow to reverse, so it should be treated as a final milestone rather than a first step. Safe rollout order: confirm HTTPS is healthy on all relevant hosts, deploy with a low max-age, raise it once confidence is established, then evaluate includeSubDomains and preload as separate 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
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"Rollout 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.
Frequently Asked Questions
A missing HSTS header means the HTTPS response does not include Strict-Transport-Security. Browsers then retry HTTP on later visits, which lets an on-path attacker intercept the first request before the redirect. Confirm the live HTTPS response, not only origin config. Add the header on Nginx, Apache, or the CDN edge that users actually hit. Re-test with the free Vulnify HSTS checker — no signup.