What is HSTS and does my website need it?

You ran a security scan on your website and one line says “HSTS missing” or “HSTS too short”. Your site already has the padlock and loads over https. So what is left to fix?

Short answer: HSTS closes a small gap that the padlock alone leaves open. For most business websites it is worth having, but it should be switched on carefully, because a mistake can lock visitors out. This guide explains it in plain English.

What HSTS means

HSTS stands for HTTP Strict Transport Security. It is a short instruction your website sends to every visitor’s browser. The instruction says: “From now on, only ever talk to me over the secure https version. Never use the plain http version, and do not let the visitor click past a certificate warning.”

Mozilla’s developer documentation describes it the same way: HSTS informs browsers that a host should only be accessed over https, and that any future attempt to use http is automatically upgraded to https. The browser remembers the instruction for a length of time that you choose.

The gap the padlock leaves open

Most sites send people from http to https with a redirect. That is good, but look at what happens when someone types your address without “https” or follows an old link:

1. Their browser first asks for the plain http version.
2. Your site answers: “please go to the https version instead.”
3. The browser follows.

Step 1 happens in the open. On public wifi, such as a cafe, an airport or a hotel, someone on the same network can interfere in that first step. The preload list project run by Google’s Chrome team describes this as a protocol downgrade: an attacker on the network intercepts and rewrites the redirect so the browser keeps using plain http. The visitor sees a normal looking page, but whatever they type, such as a password or card details, can be read or changed on the way.

HSTS shuts this down. Once a browser has seen your HSTS instruction, it changes http to https by itself, before anything is sent over the network. There is no open first step left to attack. The same documentation notes a second benefit: if something is wrong with the certificate, the browser will not let the visitor click through the warning. That blocks attackers who show a fake certificate and hope people click “continue anyway”.

The honest limits

HSTS is useful, but it is not a magic shield.

• The very first visit is not covered. A browser can only follow the instruction after it has received it once. A person who has never visited your site is still exposed on that first visit. Chrome keeps a built-in “preload” list of sites to close even this gap, but the same project says the benefits of preloading are minimal compared to HSTS itself, and that preloading is not recommended for most sites.
• It does not stop hacking. HSTS protects the connection between your visitor and your site. It does nothing about weak passwords, old plugins or a stolen login. See our guide on what to do if your WordPress site is hacked.
• Modern browsers already help a little. Some browsers try the https version first on their own. HSTS is still the way to make sure it happens every time, in every browser.

When it can backfire

This is the part many guides skip. Because the browser remembers the instruction, you cannot quietly undo it. If you tell browsers “https only” for a year and then your certificate expires or one of your subdomains does not support https, visitors will be blocked, and they cannot click past the error.

Two situations cause most of the trouble:

1. Subdomains. There is an option to apply the rule to every subdomain of your domain, such as shop.yourcompany.com or mail.yourcompany.com. That is stronger, but any subdomain that still runs on plain http, including old test sites and internal tools, will stop working for visitors who have the rule stored.
2. The preload option. OWASP, the open security community, warns that sending the preload option can have permanent consequences and can stop users reaching your site and its subdomains if you ever need to go back to http. Removal from the browser lists takes a long time.

Because of this, the Chrome preload project recommends rolling HSTS out in stages. You start with a very short memory time, then raise it step by step, checking for broken pages and watching your traffic at each stage and waiting the full time before moving on. The last stage lasts a month.

So, does your website need it?

Our view, which you can weigh against your own situation:

• Yes, if your site takes logins, orders or payments, or collects enquiry forms. Anything a visitor types in is worth protecting from the public wifi problem.
• Probably, even for a simple brochure site. The cost is low once https works everywhere, and security scans flag its absence.
• Not yet, if your https setup is shaky. If you have certificates that expire without anyone noticing, or subdomains nobody has checked, fix those first. Turning on HSTS over a broken setup turns small problems into outages.

If you are not sure, the first job is simply to find out: does your site send the instruction at all, and for how long? A good scan will tell you.

What to ask your host or developer

You do not need to touch any settings yourself. Ask these questions and write down the answers:

1. Does our site send an HSTS instruction today? For how long do browsers remember it?
2. Do all our subdomains, including old and test ones, work properly over https?
3. Is our certificate renewed automatically, and who is told if renewal fails?
4. If we turn this on, do we do it in stages, and who checks the site between stages?
5. Do we want the stronger subdomain option or the preload option, and what is the plan if we ever need to undo it?

If the answers are vague, that is useful information in itself.

Want us to check yours?

Start with the free website security checker. It looks at your site from the outside, the way a stranger would, and tells you in plain English whether browsers are being told to always use https, and whether that instruction lasts long enough. If it shows a gap and you would like it closed safely and in the right order, see our website security service.

• Email hello@wpfoss.com
• WhatsApp +254 118 271 160
• Tell us what you need

Sources and further reading

• Strict-Transport-Security header, MDN Web Docs. Source for what HSTS does, the browser upgrading http to https, and blocking click-through on certificate errors.
• HTTP Strict Transport Security Cheat Sheet, OWASP. Source for the subdomain risks and the warning that the preload option can have permanent consequences.
• HSTS Preload List Submission, Chrome team. Source for protocol downgrade attacks, the first-visit limit, the staged rollout, and the view that preloading is not recommended for most sites.
• RFC 6797: HTTP Strict Transport Security, IETF. The standard that defines HSTS (November 2012).