What Is HSTS? How to Enable the Strict-Transport-Security Header Safely

In short: What is HSTS? HSTS (HTTP Strict Transport Security) is a security header in which your server tells the browser "from now on, connect to this site over HTTPS only". The browser remembers that rule for the time you set, quietly turns http addresses into https and does not let visitors click through an invalid certificate warning. To use it safely, make sure every hostname you run works over HTTPS first, then enable the header with a short lifetime and raise it in stages.

You have moved your site to HTTPS and redirect every http address with a 301. That is a good start, but the very first request still travels unencrypted, and someone in the middle can tamper with that redirect. HSTS closes this gap. In this article we explain how HSTS works, what each setting in the header means, how to switch it on without locking yourself out and why you should not rush into the preload list.

What is HSTS and how does it work?

HSTS is an HTTP response header called Strict-Transport-Security, defined in RFC 6797. When a browser receives this header over HTTPS, it adds the domain to its own HSTS list. According to the MDN documentation, from then on:

• Every http request to that domain is rewritten to https before it is sent, and port 80 becomes 443.
• If the certificate is invalid, the browser gives the visitor no option to ignore the warning and continue.
• The rule lasts for the max-age in the header, and every new response starts that period again.

One important detail: if the header is sent over plain HTTP, the browser ignores it. HSTS also applies to domain names only, never to IP addresses.

Which attacks does HSTS protect against?

HSTS is aimed at an attacker sitting between the visitor and your server. Picture a visitor joining a fake Wi-Fi network in a café. Without HSTS, the browser's first http request can be read, and the attacker can block the redirect to https. hstspreload.org lists the cases HSTS helps with:

• Protocol downgrades: An attacker cannot intercept the http to https redirect and keep the browser on an unencrypted connection.
• Cookie hijacking: On unencrypted requests, cookies can be seen and modified; HSTS prevents those requests in the first place.
• Browsing history leaks: When someone clicks an http link, the path is not exposed on the network because the request goes straight to https.

HSTS does not protect your application layer. Form attacks and malicious requests need separate measures such as a WAF (web application firewall).

What do the settings in the HSTS header mean?

How do you enable HSTS step by step?

1. Finish HTTPS first: Install a valid SSL certificate and make every http address redirect to https with a 301. Our HTTP to HTTPS migration guide covers the details.
2. List your subdomains: Check that www, mail, panel, test and every other subdomain, including internal ones, work over HTTPS.
3. Start with a short lifetime: Add the header with 5 minutes (300 seconds) first. On Apache this is done with mod_headers, and on Nginx with the second line below:

Header always set Strict-Transport-Security "max-age=300; includeSubDomains"

add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;

4. Raise it in stages: hstspreload.org recommends stages of 1 week (604800) and 1 month (2592000). Watch for broken pages at each stage and wait the full length of a stage before moving to the next.
5. Move to a long lifetime: If nothing breaks, raise the value to something long such as 1 year (31536000). With a fixed value, every visit starts the period again.

Should you join the HSTS preload list?

HSTS has one weak spot: on the very first visit, the browser does not know the rule yet. The preload list is a list of domains built into browsers to protect that first visit too. To apply, you need a valid certificate, an http to https redirect on the same host, HTTPS on every subdomain and a header on the base domain with a max-age of at least 1 year plus includeSubDomains and preload.

Even so, hstspreload.org recommends HSTS but does not recommend preloading. Many browsers already try to upgrade http navigations to https, so the extra benefit of preloading is limited, while getting removed from the list can take months. If you are not sure that every subdomain will run on HTTPS for the long term, leave preload out.

How can you check that HSTS is working?

• Command line: curl -sI https://yourdomain.com | grep -i strict-transport-security shows the header and its value.
• Browser developer tools: Open the page, select the first request in the Network tab and look for the strict-transport-security line in the response headers.
• Chrome: On chrome://net-internals/#hsts you can query your domain and see the rule the browser has stored.

Common HSTS mistakes

• A long lifetime and preload on day one: A subdomain that is not ready can become unreachable for visitors for months.
• Adding the header to http responses: Browsers ignore it there; the header only works on HTTPS responses.
• Missing a certificate renewal: With HSTS on, an expired certificate gives visitors no way past the warning, so the site becomes completely unreachable. Review your CAA record as well to limit who may issue certificates for you.
• Switching it off the wrong way: Removing the header is not enough; you need to send max-age=0 over HTTPS.

Summary

HSTS is the final security step for a site that has moved to HTTPS: it tells browsers to reach the site over encrypted connections only and stops visitors from clicking through certificate errors. Finish HTTPS and your redirects first, check your subdomains, enable the header with a short lifetime and raise it in stages, and only consider preload as a long-term decision. If you are not sure where to add the header for your site at ÇAP Hosting, our support team can work through it with you.

Frequently Asked Questions