iFastHostingWhat is HSTS?
A header that tells browsers to never even attempt the insecure version of your site again, closing a gap a redirect alone leaves open.
HSTS — HTTP Strict Transport Security — is a response header that tells a browser: for this domain, do not ever attempt a plain HTTP connection again, go straight to HTTPS. Once a browser has seen the header once, it applies that rule for the length of time the header specifies, without needing to check with the server again first.
Why a redirect alone is not quite enough
A server-side redirect from HTTP to HTTPS, covered in how to force HTTPS on your site, still requires the browser to make that first, brief, insecure request before it gets redirected. In that narrow window, someone positioned on the network — a rogue public Wi-Fi hotspot is the classic example — could intercept the initial plain HTTP request before the redirect happens, and either read it or serve back something other than the real redirect. HSTS closes that window by having the browser skip the insecure attempt entirely on any visit after the first.
What the header looks like
Strict-Transport-Security: max-age=31536000; includeSubDomainsmax-age is how long, in seconds, the browser should remember the rule — the value above is one year. includeSubDomains extends the rule to every subdomain of the current domain as well, not just the exact address that sent the header.
Once a browser has stored the rule, it will refuse to load the site over HTTP at all — including on any subdomain, if includeSubDomains is set — until the max-age expires or the browser is told otherwise. If HTTPS is not yet working reliably across the whole domain and every subdomain you care about, HSTS turns a fixable mistake into visitors being locked out until the stored rule expires.
The preload list
Browsers also maintain a hardcoded preload list of domains that should always use HTTPS, checked before the browser has ever visited the site at all — which removes even that first visit's exposure. Submitting a domain adds an optional preload directive to the header and requires meeting stricter requirements first, including HTTPS working correctly across every subdomain without exception.
Removing a domain from the preload list takes far longer than adding one, since it depends on the list being rebuilt and redistributed with every browser update. Only add preload once you are certain every subdomain will run HTTPS indefinitely.
How to add it
HSTS is set the same way as any other security header — through your application, or via your web server configuration. It is covered together with the other headers worth setting in how to add security headers to your site. A sensible order is: confirm HTTPS works everywhere, add the redirect, run with just the redirect for a while, then add HSTS with a modest max-age before extending it, and only add preload once you are fully confident nothing on the domain still depends on plain HTTP.
Related reading
A certificate being installed does not redirect anyone by itself. Here is the rule that sends every visitor to the secure version automatically.
How to add security headers to your siteA handful of response headers close off entire categories of attack for very little effort. Here is what each does and how to add them.
Why does my site still say "Not secure"?A certificate can be installed correctly and the warning can still appear — usually for one of a handful of specific, fixable reasons.
A practical website security checklistThe handful of specific, checkable things that account for most of what a secure website setup actually needs, in the order to do them.