HSTS explained: what it protects against, and the preload decision
HTTP Strict Transport Security (HSTS) forces browsers to use only HTTPS connections to your domain, preventing users from bypassing certificate warnings, according to the OWASP HSTS Cheat Sheet.
What HSTS does
This policy is applied on an "entire-host" basis, meaning it applies to HTTP over any TCP port of the issuing host (RFC 6797). Once a browser receives this header, it will terminate any secure transport connection attempts upon any and all secure transport errors or warnings, removing the user's ability to "click through" security prompts (RFC 6797).
The threats it addresses
HSTS is designed to counter specific threat classes: passive network attackers, active network attackers, and imperfect web development bugs (RFC 6797). A key vulnerability is "click-through insecurity," where users accept invalid certificate warnings, which can lead to session hijacking if authentication cookies are stolen (RFC 6797).
It also mitigates risks from mixed content, where an otherwise secure page loads a resource like a script or stylesheet over an insecure HTTP connection, potentially allowing an attacker to control the page (RFC 6797). HSTS automatically redirects HTTP requests to HTTPS for the target domain, protecting users who manually type http:// or follow outdated links (OWASP HSTS Cheat Sheet).
Implementing the header
The policy is declared via the Strict-Transport-Security HTTP response header sent over a secure HTTPS connection (MDN). The primary directive is max-age=<expire-time>, which specifies the time in seconds the browser should remember the policy (MDN). For comprehensive coverage, include the includeSubDomains directive to apply the policy to all subdomains of the host's domain (MDN).
A common and secure configuration is: Strict-Transport-Security: max-age=63072000; includeSubDomains (OWASP HSTS Cheat Sheet).
The preload list decision
A major limitation of HSTS is that it only takes effect after the browser has made at least one secure connection to the host and received the header (MDN). Preloading ensures browsers will only connect via HTTPS from the very first visit.
To qualify for preloading, your site must serve the header with a max-age of at least 31536000 seconds (1 year), the includeSubDomains directive, and the preload directive (MDN). Crucially, sending the preload directive can have permanent consequences, as removal from the list is a slow and difficult process (OWASP HSTS Cheat Sheet). You should only commit to preloading once you are certain all present and future subdomains can support HTTPS indefinitely.
Frequently asked questions
Do I actually need HSTS?
If your site uses HTTPS, HSTS is a necessary defense-in-depth control. It eliminates the risk of the first HTTP request being intercepted and prevents users from accidentally bypassing certificate errors, which active network attackers can exploit (RFC 6797).
What happens if I need to revert to HTTP after enabling HSTS?
If you set a long max-age without preloading, you can send a new header with max-age=0 over HTTPS to instruct browsers to expire the policy (MDN). However, if your domain is on the HSTS preload list, removal is a lengthy process and users with updated browser lists will be unable to access your site over HTTP for a long time (OWASP HSTS Cheat Sheet).
Does HSTS protect all my subdomains?
Only if you use the includeSubDomains directive. Without it, the HSTS policy applies only to the exact host that sent the header (MDN). For full protection, each subdomain should also send its own HSTS header, even if the superdomain uses includeSubDomains (MDN).
Where to start
Begin by configuring your web server to send the Strict-Transport-Security header with a moderate max-age and includeSubDomains. Once confident, evaluate the long-term commitment of submitting to the HSTS preload list, as it can have permanent consequences and prevent users from accessing your site and any of its subdomains if you need to switch back to HTTP as noted in the OWASP HSTS Cheat Sheet.
Sources
---
_Researched with AI assistance from a live passive security scan run by NEL (scan eph_mtgjkevg_gss), which was not retained; citing 4 external sources; 23 factual claims were extracted and checked against their sources (23 of 23 verified); each verification step was independently recorded and signed by Vitna, which attests that the check ran and what its verdict was — not that the underlying claim is true (records ac8b53a5-4588-4bf4-bcc7-55199ebc92fb, b2184ba2-de51-49db-972b-29a7b3f37648, 8be75ce4-68d7-40e8-a9bf-6d97a4847103, +127 more, verify at https://vitna.costrinity.xyz/api/evidence/verify); released automatically after every check above passed; not reviewed by a human before publication; published by NEL Professionals with no individual byline._
Get up to 100 scans or unlimited lifetime access starting at $15.
View Plans →Comments (0)
No comments yet. Be the first to comment!