In the world of web security, HTTP Strict Transport Security (HSTS) is a heavyweight tool. It forces browsers to talk to your site only over secure HTTPS connections, stopping common attacks cold. So why do so many teams get it wrong?
First, What Is HSTS Supposed to Do?
Imagine telling a web
browser, "From now on, only ever talk to my website using the secure, encrypted HTTPS protocol. Never use plain HTTP again." That's HSTS in a nutshell. It's a response header your server sends that tells the browser to enforce this rule for a set period. This is a powerful defense against man-in-the-middle attacks where an attacker tries to downgrade a user's connection to insecure HTTP to steal data, a technique known as SSL stripping. It also prevents users from clicking through scary-looking certificate warnings, which is often how they fall into an attacker's trap. Once a browser receives the HSTS header, it remembers the policy. The next time you type `http://example.com`, the browser itself changes it to `https://example.com` before the request even leaves your machine.
Mistake 1: Treating It as 'Set and Forget'
The most common misunderstanding is treating HSTS like a simple switch you flip on. The policy includes a `max-age` directive, which tells browsers how long, in seconds, to cache the rule. Teams often either set this value too low, defeating the purpose, or too high without proper testing. Setting a low `max-age` (like a few minutes) means the window of protection is tiny, offering a false sense of security. Conversely, setting a `max-age` of one or two years without a gradual rollout is like pouring concrete without checking if the foundation is right. If you make a mistake, browsers that have received the header will refuse to connect to your site over HTTP for that entire duration, making rollbacks incredibly difficult. The best practice is to start with a very short `max-age`, test everything, and gradually increase it over weeks or months.
Mistake 2: The 'includeSubDomains' Blind Spot
The HSTS header has a potent option: `includeSubDomains`. When enabled, the policy applies not just to your main domain (like `example.com`) but to every single subdomain under it (`blog.example.com`, `api.example.com`, `internal-tool.example.com`). This is where many teams find themselves in trouble. An IT department might enable this, not realizing the marketing team uses a third-party service at `clicks.example.com` that doesn't fully support HTTPS. Suddenly, all email click-tracking breaks. Or a forgotten internal tool that was never configured for HTTPS becomes completely inaccessible to employees whose browsers have received the HSTS policy. Before flipping this switch, a complete audit of every subdomain, including internal, legacy, and third-party delegated ones, is non-negotiable.
Mistake 3: Rushing to the 'Preload' List
For maximum security, you can submit your domain to the HSTS preload list, which is hardcoded into major browsers like Chrome, Firefox, and Safari. This eliminates the "first visit" vulnerability, where an attacker could strike before the browser has received an HSTS header. However, this is a semi-permanent commitment. Getting on the list requires you to set `includeSubDomains` and a long `max-age`. The biggest mistake is submitting for preloading before you are 100% certain that your entire domain ecosystem can live on HTTPS forever. Removing a domain from the preload list is a slow, painful process that can take months to propagate to all users, leaving broken sites and subdomains inaccessible for an entire browser release cycle or longer.
