Why Your Website Needs HSTS in 2026
One header, one config line, and downgrade attacks stop reaching your users. If your site doesn't ship HSTS in 2026, you're leaving free security on the table.
What HSTS actually does
HTTP Strict Transport Security (HSTS) is a single response header that tells a browser one thing: for the next N seconds, never talk to this hostname over plain HTTP. Once the browser has seen the header, every http:// link, every typed URL, every old redirect and every bookmarked page for that host is silently rewritten to https:// before a single packet leaves the device. That rewrite happens inside the browser, before the network request exists. There is no round trip to your server that an attacker can intercept, because there is no HTTP round trip at all. The header looks like this: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. The max-age value is how long, in seconds, the browser should remember the rule — 63072000 is two years, the value the preload list expects. The includeSubDomains directive extends the rule to every subdomain, which matters more than most people realize: without it, a single insecure blog.example.com can be used to plant or steal cookies scoped to the parent domain.
The attack it stops
The threat HSTS closes is the SSL-stripping man-in-the-middle. Picture a user on open airport Wi-Fi who types example.com into the address bar. The browser's first instinct is to try http://example.com, expecting a redirect to HTTPS. An attacker sitting on that network answers first, keeps the connection on plain HTTP between themselves and the victim, and quietly proxies HTTPS to your real server. The padlock is missing, but most users never look. Everything the victim types — passwords, session cookies, payment details — flows in clear text to the attacker. Your server sees a perfectly normal HTTPS session and has no idea anything is wrong. HSTS removes the vulnerable first hop entirely. After the browser's first secure visit, it refuses to make that initial HTTP request ever again, so there is nothing for the attacker to hijack. It is one of the few defenses that eliminates a class of attack rather than merely detecting it.
Why it matters in 2026
HTTPS is no longer optional, and the ecosystem now treats HTTP as actively broken. Chrome and Safari label plain HTTP pages as Not Secure in the address bar. Search engines use HTTPS as a ranking signal and demote insecure pages. A growing list of browser capabilities — Service Workers, the Web Crypto API, WebAuthn passkeys, Push notifications, the Geolocation API — simply refuse to run outside a secure context. If your site already serves everything over HTTPS, HSTS costs you nothing and removes the last insecure edge case. If it doesn't, that is the first problem to fix, and HSTS is the natural finish line once it's done. There is genuinely no scenario in 2026 where leaving HSTS off is the right call for a production site. The return on investment is lopsided: a few minutes of configuration buys you protection against an entire category of network attack, plus a small SEO and trust benefit, with no ongoing maintenance.
How to ship it
Start conservatively. Set a short max-age first so a mistake expires quickly: Strict-Transport-Security: max-age=300. Confirm every page, asset and subdomain still loads correctly over HTTPS. Then raise the value in stages — a day, a week — and finally to two years with includeSubDomains once you are confident. Where you set the header depends on your stack. On Nginx, add add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; inside your server block. On Apache, use Header always set Strict-Transport-Security. Behind Cloudflare, you can enable HSTS from the SSL/TLS settings with the same options in a UI. On a platform like Vercel or Netlify, add it to your headers configuration file. Then verify. Run your domain through Website Auditor and confirm the header is present, has a max-age of at least six months, and includes the subdomains directive. The scanner will flag a weak max-age or a missing includeSubDomains so you don't ship a half-measure.
Preloading safely
The preload directive opts your domain into a list that Chrome, Firefox, Safari and Edge all ship inside the browser binary. Once you are on it, browsers enforce HTTPS for your domain on the very first visit, before they have ever seen your header — closing the tiny window that exists for a brand-new visitor. To qualify, submit your domain at hstspreload.org. The requirements are strict: a valid certificate, a redirect from HTTP to HTTPS on the same host, HSTS served on the base domain with max-age of at least one year, plus includeSubDomains and preload. The catch is that preload is effectively permanent. Every subdomain you own must work over HTTPS, forever, or it becomes unreachable in preloading browsers. Removal is possible but can take months to propagate through browser releases. Only preload once you are certain every current and future subdomain — including internal tools and staging hosts on that domain — has a valid certificate.
Common pitfalls
The mistake that scares people off is enabling includeSubDomains or preload before every subdomain is HTTPS-ready. If dev.example.com or an old mail host only speaks HTTP, HSTS will make it unreachable in browsers that have cached the rule. Inventory your subdomains first. A second trap is setting HSTS on a response served over HTTP. Browsers ignore the header unless it arrives over a valid HTTPS connection, so it must be attached to your HTTPS responses, not your redirect. Third, remember that HSTS does not replace the HTTP-to-HTTPS redirect — it complements it. The redirect handles the first visit and any client that has never seen your header; HSTS handles every visit after that. Ship both. Finally, HSTS is not a substitute for a correct certificate or a strong Content-Security-Policy; it is one layer in a defense-in-depth stack, and it happens to be the cheapest layer you will ever add. If you take one thing away, make it this: get every page onto HTTPS, add the redirect, then ship HSTS with a growing max-age and includeSubDomains. Confirm it with a scan, and only reach for preload once you are certain every subdomain will speak HTTPS indefinitely. Done in that order, HSTS is a five-minute change that permanently removes an entire class of downgrade attack — and it is the kind of quiet, structural fix that keeps paying off for years without ever asking for your attention again.
Frequently asked questions
- Only if HTTPS itself breaks. HSTS does not disable HTTP on your server — it tells browsers not to use it. If your certificate expires or HTTPS goes down while a browser is enforcing HSTS, users cannot reach the site until HTTPS works again, which is exactly why you automate certificate renewal and start with a short max-age.
- Start at 300 seconds while testing, then move to 63072000 (two years) for production. The preload list requires at least 31536000 (one year). A value under six months is treated as weak by most scanners.
- It is not strictly required for basic HSTS, but it is required for preloading and strongly recommended otherwise. Without it, an insecure subdomain can be used to attack cookies scoped to your main domain. Only add it once every subdomain serves HTTPS.
- Indirectly. HSTS enforces HTTPS, and HTTPS is a confirmed Google ranking signal. More importantly it removes Not Secure warnings that hurt trust and conversion. It is not a direct ranking factor on its own.