What is HTTP Strict Transport Security (HSTS) and Why Every Site Needs It
A complete guide covering how HSTS works, why it matters, how browsers enforce it with 307 internal redirects, the preload list, and how to verify your site is protected.
Your site has an SSL certificate. It redirects HTTP to HTTPS. You might think that is enough to keep traffic encrypted. It is not. There is a brief moment during that redirect where a request travels over plain HTTP, completely unencrypted. That moment is exactly what attackers exploit.
HTTP Strict Transport Security (HSTS) closes that gap. It is a single HTTP response header that tells browsers to skip HTTP entirely and connect over HTTPS from the start. No redirect needed, no unencrypted moment, no opportunity for interception.
This guide explains what HSTS does, how browsers enforce it, what the header looks like, how the preload list works, and how to verify your own site is protected.
The problem HSTS solves#
When someone types example.com into their browser (without the https:// prefix), the browser defaults to HTTP. It sends a plain text request to port 80. Your server receives it and responds with a 301 or 302 redirect to the HTTPS version. The browser follows the redirect and loads the page securely.
That sounds fine, but there is a problem. The first request, the one to port 80, travels across the network without any encryption. Anyone sitting between the user and your server can see it, modify it, or respond to it before your server does.
This is not a theoretical concern. It is a documented attack technique called SSL stripping, and it works on any network where the attacker can intercept traffic. Public Wi-Fi at a coffee shop, an airport, a hotel, or even a compromised router on a home network.
How SSL stripping works#
An SSL stripping attack is straightforward. The attacker positions themselves between the victim and the internet (a technique called a man in the middle position). When the victim's browser makes that initial HTTP request, the attacker intercepts it. Instead of forwarding it to the real server, the attacker opens their own HTTPS connection to the real server, fetches the page content, strips the HTTPS from all the links, and sends a plain HTTP version back to the victim.
From the victim's perspective, the site loads normally. It just stays on HTTP. There is no certificate warning because no certificate is being used. The attacker can read everything the victim submits: login credentials, credit card numbers, personal data. They can also modify the page content before the victim sees it.
1. User types example.com
2. Browser sends HTTP request (plain text, port 80)
← Attacker intercepts this request
3. Attacker connects to example.com over HTTPS
4. Attacker sends HTTP version back to user
5. User sees the site over HTTP (no lock icon)
6. All data the user submits is visible to attacker1. User types example.com
2. Browser knows HSTS is active for this domain
3. Browser upgrades to HTTPS internally (307 redirect)
4. Browser sends HTTPS request directly (encrypted)
5. No HTTP request ever leaves the browser
6. Attacker has nothing to interceptThe key difference is step 2. With HSTS, the browser does not contact your server over HTTP at all. The upgrade happens inside the browser before any network request is made. This eliminates the window of vulnerability that SSL stripping exploits.
What the HSTS header looks like#
HSTS is a single HTTP response header called Strict-Transport-Security. Your server includes it in every HTTPS response. Here is the full header with all three directives:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadThat single line has three parts. Each one controls a different aspect of how the browser enforces HTTPS on your domain.
max-age (required)
The number of seconds the browser should remember to use HTTPS. A value of 31536000 equals one year. Every time the browser visits your site and sees this header, the timer resets. If a user visits your site once a year, the HSTS policy stays active indefinitely.
includeSubDomains (recommended)
Applies the HSTS policy to every subdomain of your site. Without this, example.com would be protected but api.example.com or blog.example.com would not. Since attackers can target any subdomain, you should include this directive.
preload (opt in)
Signals that you want your domain added to the browser's built in preload list. This is not just a directive that browsers enforce on their own. You must also submit your domain at hstspreload.org after adding this directive. More on the preload list below.
How browsers enforce HSTS#
When a browser receives a response with a Strict-Transport-Security header over HTTPS, it stores the domain and the max-age value internally. From that point forward, any attempt to load that domain over HTTP triggers an internal redirect.
You can see this in Chrome's DevTools. Open the Network tab, type an HTTP URL for an HSTS protected site, and you will see a 307 Internal Redirect as the very first entry. This is not your server responding. This is the browser itself rewriting the URL to HTTPS before any network request is sent. The HTTP request never leaves the machine.
Browsers only accept the HSTS header over HTTPS. If your server sends the header over an HTTP response, browsers ignore it completely. This is a security measure. If an attacker could set HSTS over HTTP, they could force a victim's browser to only connect to a domain they control over HTTPS.
This means the first visit to your site still relies on the HTTP to HTTPS redirect. HSTS protects every visit after that. The only way to protect the very first visit is through the preload list.
The HSTS preload list#
The HSTS preload list is a list of domains that is hardcoded directly into Chrome, Firefox, Safari, Edge, and other browsers. When a domain is on this list, the browser enforces HTTPS from the very first connection, even if the user has never visited the site before. There is no trust on first use problem.
The list is maintained by the Chromium project, and other browsers adopt it. As of early 2026, the list contains over 100,000 domains. To get your domain added, you need to meet all of the following requirements:
- Serve a valid SSL certificate for your domain and all subdomains
- Redirect all HTTP traffic to HTTPS on the same host (before any other redirect)
- Serve the HSTS header on the base domain over HTTPS with a
max-ageof at least 31536000 (one year) - Include the
includeSubDomainsdirective - Include the
preloaddirective
Once your header meets these requirements, submit your domain at hstspreload.org. The review process typically takes a few weeks, and once accepted, your domain will be included in the next browser update. Keep in mind that removal from the preload list is also possible but takes months, so make sure HTTPS works reliably across your entire domain before submitting.
When HSTS can cause problems#
HSTS is not something you can casually turn on and forget about. Because browsers take the header seriously and enforce it strictly, mistakes can lock users out of your site. Here are the situations to watch out for:
Expired or misconfigured SSL certificate
If your SSL certificate expires and HSTS is active, browsers will refuse to load your site entirely. There is no "proceed anyway" option. The browser shows a hard error that the user cannot bypass. This is by design, because allowing the user to bypass it would defeat the purpose of HSTS.
Subdomains without HTTPS
If you use includeSubDomains but have subdomains that do not support HTTPS (like an internal staging server or a legacy service), those subdomains will become unreachable. Audit every subdomain before adding this directive.
Setting max-age too high too soon
If you set max-age=31536000 on day one and then discover a problem, every browser that visited your site will enforce HTTPS for up to a year. Start with max-age=300 (five minutes), verify everything works, then increase to 86400 (one day), then 604800 (one week), and finally 31536000 (one year).
These are not reasons to avoid HSTS. They are reasons to deploy it carefully. The incremental approach (start low, increase gradually) eliminates nearly all risk. Our HSTS generator guide walks through this step by step with server configuration examples for Apache, Nginx, and Express.
How to check if your site uses HSTS#
There are several ways to verify whether HSTS is active on your domain:
- Browser DevTools. Open the Network tab, load any page on your site, click the main document request, and look at the Response Headers section. If you see
Strict-Transport-Security, HSTS is active. - Chrome's internal HSTS page. Navigate to
chrome://net-internals/#hstsand type your domain into the "Query HSTS/PKP domain" field. Chrome will show whether it has an active HSTS entry for that domain and when it expires. - Command line. Run
curl -sI https://yourdomain.com | grep -i strictto see the raw header value from your server. - Online scanner. Use SiteSecurityScore to scan your site. The report checks for HSTS along with all other security headers and tells you whether the max-age, includeSubDomains, and preload values meet recommended settings.
HSTS and your SSL certificate#
HSTS and SSL certificates work together but serve different purposes. Your SSL certificate encrypts the connection. HSTS ensures the browser always uses that encrypted connection. Having one without the other leaves gaps.
A certificate without HSTS means the first request can still be intercepted. HSTS without a valid certificate means the browser will block access to your site entirely (because it cannot establish the HTTPS connection that HSTS requires).
If you use a certificate authority like Let's Encrypt with automatic renewal, HSTS is safe to enable. The combination of auto-renewing certificates and HSTS gives you the strongest transport security posture available. Just make sure the renewal process is tested and monitored, because a failed renewal with HSTS active is much more disruptive than a failed renewal without it.
HSTS compared to a simple redirect#
Some developers think that a 301 redirect from HTTP to HTTPS is equivalent to HSTS. It is not. Here is why they are fundamentally different:
| 301 Redirect | HSTS | |
|---|---|---|
| Where it happens | Server side (requires HTTP request first) | Browser side (no HTTP request needed) |
| Prevents SSL stripping | No | Yes (after first visit) |
| First visit protected | No | Only with preload list |
| User can bypass | Yes (attacker prevents redirect) | No (browser enforces it) |
| Extra round trip | Yes (HTTP request + redirect) | No (browser rewrites instantly) |
You should still have the 301 redirect in place. It handles the very first visit from browsers that have not yet received your HSTS header and the very first visit from browsers that do not support HSTS (though all modern browsers do). HSTS and the redirect work together. The redirect handles the initial visit, and HSTS protects every visit after that.
What a complete HSTS setup looks like#
Putting it all together, a properly configured site with HSTS has these layers working in combination:
- Valid SSL certificate with automatic renewal, covering the root domain and all subdomains
- 301 redirect from HTTP to HTTPS on the same host
- HSTS header with
max-age=31536000; includeSubDomains; preload - Preload list submission at hstspreload.org for first visit protection
If you want step by step instructions for configuring this on your specific web server, including Apache, Nginx, and Express configurations with the incremental rollout approach, see our HSTS generator guide.
The bottom line
HSTS is one of the simplest security headers to implement and one of the most impactful. A single line in your server configuration eliminates an entire class of attacks. It protects your users on untrusted networks, speeds up page loads by removing the redirect round trip, and signals to browsers that your site takes transport security seriously.
If your site has a valid SSL certificate and serves all content over HTTPS, there is no reason not to enable HSTS. Start with a short max-age, verify everything works, increase gradually, and then submit to the preload list. Your users will never notice the difference, and that is exactly the point. Security that works invisibly is the best kind.
Frequently asked questions#
What does the Strict-Transport-Security header do?
It tells browsers to only connect to your site over HTTPS, even if the user types http:// in the address bar or clicks an HTTP link. The browser upgrades the connection to HTTPS automatically before sending any request, which prevents attackers from intercepting the initial unencrypted request.
What is the HSTS preload list?
A list of domains hardcoded into Chrome, Firefox, Safari, Edge, and other browsers that should always be loaded over HTTPS. When your domain is on the preload list, the browser uses HTTPS on the very first visit, before it has ever seen your HSTS header. You can submit your domain at hstspreload.org.
What is an SSL stripping attack?
An attack where someone intercepts the initial HTTP request before it gets redirected to HTTPS. The attacker connects to the real site over HTTPS but serves the victim a plain HTTP version, letting them read and modify all traffic. HSTS prevents this by ensuring the browser never makes that initial HTTP request.
Can HSTS lock users out of my site?
Yes, if your SSL certificate expires or you switch back to HTTP while HSTS is active, browsers will refuse to load your site for the duration of your max-age value. This is why you should start with a short max-age (like 300 seconds) and increase it gradually after confirming HTTPS works reliably.
How do I check if a website uses HSTS?
Open your browser's developer tools, go to the Network tab, and look at the response headers for any page load. Look for Strict-Transport-Security. You can also use SiteSecurityScore's free scanner, which checks for HSTS along with all other security headers.
References
Continue reading
Is your site using HSTS correctly?
Scan your website to check your HSTS configuration along with all other security headers.