Setting Up HSTS the Right Way (Without Locking Yourself Out)
HSTS forces HTTPS forever — which is exactly why a careless rollout can lock you out. Follow this safe, staged approach to enable it with confidence.
HTTP Strict Transport Security (HSTS) is a small header with enormous consequences. It tells browsers to only ever connect to your domain over HTTPS — no exceptions, no fallback — for a duration you specify. Used correctly it closes off a whole class of downgrade attacks. Used carelessly it can make your domain unreachable for months. This guide shows you how to get the benefit without the risk.
What HSTS actually does
When a browser sees the Strict-Transport-Security header, it remembers your domain as HTTPS-only for the duration of the max-age value. From then on, even if a user types http:// or clicks an old insecure link, the browser silently upgrades to HTTPS before sending anything. There is no insecure request for an attacker to intercept.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- `max-age` — how long (in seconds) the browser remembers the HTTPS-only rule.
31536000is one year. - `includeSubDomains` — applies the rule to every subdomain, not just the apex.
- `preload` — requests inclusion in the browsers' built-in HSTS list, enforcing HTTPS even on the very first visit.
Why HSTS can lock you out
The power of HSTS is also its danger. Once a browser has cached your policy, it will refuse plain HTTP for the entire max-age. If you enable includeSubDomains but one subdomain does not serve valid HTTPS, that subdomain becomes unreachable — and you cannot simply 'turn it off', because every browser that saw the header is enforcing it on its own. With preload, the rule is baked into the browser itself and removal can take months.
Once browsers cache your policy, there is no quick way to reverse it. That is exactly why you ramp up slowly instead of starting at a one-year max-age with preload.
The safe, staged rollout
- 1First, confirm every subdomain you might include serves valid HTTPS with no certificate errors.
- 2Start with a short max-age, such as
max-age=300(five minutes), and verify nothing breaks. - 3Increase to a day, then a week, watching for any subdomain issues at each step.
- 4Once confident, raise to one year and add
includeSubDomains. - 5Only when all of the above is rock solid, add `preload` and submit to the preload list.
Prerequisites you must not skip
Before enabling HSTS at all, your HTTP-to-HTTPS redirect must be working and your certificate must be valid across every hostname the policy covers. HSTS assumes HTTPS already works everywhere; it is the lock on a door that must already close properly. Enabling it to 'force' HTTPS on a site that is not fully ready is how lockouts happen.
Run a scan to verify HSTS is present and correctly configured, and that your certificate and redirects are solid across all hostnames before you raise max-age or add preload.
HSTS is one of the highest-value headers you can set — and one of the few that genuinely punishes haste. Make sure HTTPS works everywhere first, ramp the max-age up gradually, and only reach for preload once you are certain. Do it in that order and you get bulletproof HTTPS enforcement with none of the lockout horror stories.
