What is HSTS, and should I enable it?

HSTS is a response header that tells browsers to only ever reach your site over HTTPS, even when someone types http:// - it closes the brief gap where that first plain request could be intercepted and quietly downgraded. You should turn it on once your HTTPS is solid, with one caution: the "preload" option is hard to undo, so enable the header first, live with it for a while, and only preload when you are certain. 70% of Australian small-business websites do not set an HSTS header at all^*, which makes this one of the cheapest wins on the website security checklist.

What HSTS actually does

HSTS - HTTP Strict Transport Security - is a single line your server sends back with every page: Strict-Transport-Security: max-age=31536000. That number is a duration in seconds (31536000 is one year). It is an instruction to the browser: for the next year, never connect to this site over plain HTTP again, no matter what. Type the address without https://, click an old http:// bookmark, follow a link someone pasted - the browser rewrites it to HTTPS internally, before a single byte leaves the machine.

Without the header, the browser does the polite thing: it tries http://, your server replies "actually, use HTTPS" with a redirect, and the browser follows. That works, and most sites rely on it. But there is a difference between "the server asks the browser to use HTTPS each time" and "the browser refuses to use anything else." HSTS is the second one. It moves the decision off the network, where it can be tampered with, and into the browser, where it cannot.

There is one optional extra worth knowing the name of: includeSubDomains, which extends the rule to every subdomain - shop., blog., app., all of them. Useful, but only safe once you are sure every one of those subdomains genuinely serves HTTPS. That distinction matters more than it looks, and it comes back when we get to preload. The header itself is documented plainly on MDN's Strict-Transport-Security page if you want the full syntax. For the plain-English version, we keep a short note on what HSTS is.

Why it matters

The whole point of HSTS is that first request. Picture someone on café Wi-Fi typing yourbusiness.com.au into the address bar. They didn't type https:// - almost nobody does - so the browser's opening move is a plain http:// request. Without HSTS, that request travels in the clear for the split second before your redirect kicks in. On a hostile network, that split second is enough: an attacker sitting between the visitor and the internet can catch that plain request and answer it themselves, keeping the visitor on a fake http:// version of your site that never upgrades. The visitor sees your address, types their password, and the redirect that would have saved them never happens. This trick has a name - SSL stripping - and the redirect-only setup is exactly what it preys on.

HSTS shuts the window. Once a browser has seen your HSTS header even once, it remembers the rule and upgrades every future request to HTTPS before it leaves the device. There is nothing in the clear to intercept. The attacker on the café network has nothing to grab and nothing to answer.

It is worth being honest about the limit: HSTS still has to be learned. A brand-new visitor who has never been to your site, on a hostile network, on their very first request, is not yet protected - the browser hasn't seen the header yet. That residual gap is precisely what the preload list (below) is built to close. For everyone who has visited before, the protection is total. That is most of your traffic, and it costs you one line of configuration.

When you should turn it on

Turn HSTS on after your HTTPS is genuinely finished - not before. The header is a promise the browser will hold you to for a year, so the prerequisites are not optional:

• A valid certificate that you will keep renewing. If your cert lapses while HSTS is active, browsers will refuse to load your site at all, with no clickthrough. There is no "proceed anyway" button under HSTS. Auto-renewal (Let's Encrypt and most hosts do this for you) makes this a non-issue, but confirm it is on.
• Every page already served over HTTPS, with no mixed content. If pages still pull an image, script, or stylesheet over http://, fix that first - see what mixed content is. HSTS will force those sub-requests to HTTPS too, and anything that only exists on http:// will simply break.
• An HTTP→HTTPS redirect already in place and working. HSTS is the belt to your redirect's braces, not a replacement for it. The redirect handles the brand-new visitor; HSTS handles every visit after. You want both - more on the ordering in do I need to redirect HTTP to HTTPS. If HTTPS itself isn't fully sorted yet, start there: how to add HTTPS to your website.

With those three true, enabling HSTS is a small change wherever your headers are set - your host's control panel, your CDN (Cloudflare has a one-click toggle), or your server config. Start with a short max-age if you want to be cautious - say a few hours - confirm nothing breaks, then raise it to a year. It is one of several headers worth setting together, which is why we treat it as part of what security headers your site needs rather than a standalone job. While you are in there, it is also worth checking your TLS version is current - TLS 1.2 vs TLS 1.3 explains why.

The preload caution

There is a further step called preload, and it is the one place HSTS can genuinely bite you. The browser-learns-the-rule model has that one gap: a first-ever visitor isn't protected until the browser has seen your header once. Preload closes it by baking your domain into a list - the HSTS preload list - that ships inside the browser itself. Chrome, Firefox, Safari, and Edge all draw from it. Once your domain is on that list, every one of those browsers treats your site as HTTPS-only from the very first request, before it has ever connected. The protection is complete.

The catch is that getting off the list is slow and awkward. You submit your domain at hstspreload.org with preload added to your header; the change then has to propagate into a new browser release and roll out to everyone, which takes months. Until it does, every preload-aware browser flatly refuses to reach any part of your site over HTTP. If a subdomain isn't on HTTPS - an old mail. host, a legacy status. page, a forgotten dev box - it becomes unreachable, and you cannot quickly take it back. Preload requires includeSubDomains, so it is an all-or-nothing promise across your entire domain.

The order that keeps you out of trouble: enable the plain HSTS header, run it at a one-year max-age for a good while, confirm every subdomain you own is happily on HTTPS and will stay that way - then, and only then, consider preload. There is no urgency. The header alone protects essentially all your real traffic; preload only closes the never-visited-before edge case, and it is not worth rushing into a commitment that takes months to reverse.

When this isn't enough

HSTS is a narrow, sharp tool: it guarantees the connection to your site is encrypted and cannot be downgraded. That is real, and it is one line. But it says nothing about whether the rest of your site is set up correctly. It does not stop your domain from being spoofed in email - that is SPF, DKIM, and DMARC. It does not set the other security headers a browser looks for - and HSTS is only one of those, so it helps to know what a security header is in general. It does not patch an out-of-date CMS, and it does not catch the configuration that silently breaks the next time someone rebuilds your site.

The point is that HSTS is one item on a longer, mostly-one-time list - and like the rest of that list, it is the sort of thing nobody re-checks after a provider change. The ACSC's Small Business Cyber Security Guide puts the website basics in the context of the handful of other controls that actually matter at small-business scale: backups, updates, multi-factor authentication. Worth reading alongside this. And if you would rather just see where your own site stands - HSTS, the other headers, your certificate, your email records - run a scan and check it against the website security checklist. The fixes are nearly always small. The trick is knowing which ones are missing.