What is HTTP Strict Transport Security and how does it work

Most website owners assume that switching to HTTPS is enough to keep their visitors safe. Install an SSL certificate, set up a 301 redirect from HTTP, and the job is done. But there's a gap in that logic, one that attackers have been exploiting for years.

The very first time a user types your domain into a browser, before any redirect kicks in, their request travels over plain HTTP for a split second. That's all the window a man-in-the-middle attack needs to intercept the connection and strip away your HTTPS entirely. HTTP Strict Transport Security (HSTS) was designed specifically to close that gap.

In this guide, you'll learn exactly what HTTP Strict Transport Security is, how the HSTS header works under the hood, and how to implement it correctly on your server.

What is HTTP Strict Transport Security?Link to heading

HSTS is a widely adopted web security mechanism whose primary purpose is to force browsers to access websites over HTTPS instead of HTTP. The Internet Engineering Task Force (IETF) formally defined this standard in RFC 6797, published in 2012.

When a domain has HSTS enabled, it instructs the browser to always use HTTPS, whether the user clicks an HTTP link or types a URL without specifying a protocol. It also prevents users from bypassing certificate warning pages. By handling this redirect automatically, HSTS removes any possibility of the site being accessed over an unencrypted connection.

When a browser connects to an HSTS-enabled domain or subdomain, the server responds with a Strict-Transport-Security header. This header tells the browser to enforce HTTPS and store that instruction for a set period of time, measured in seconds. Any future attempt to reach the domain over HTTP is automatically upgraded to HTTPS before the request even leaves the browser.

At its core, HTTP Strict Transport Security protects against man-in-the-middle attacks and ensures that both the main domain and its subdomains are always accessed securely. For this to work correctly, every subdomain under the parent domain must also support HTTPS.

>>> Learn more: What is an SSL port? Default ports, setup & troubleshooting

Why is it important to use HSTS?Link to heading

Several real-world browsing behaviors create security gaps that HSTS is designed to close. When a user types a web address such as "test.com" directly into the browser bar, the browser defaults to HTTP rather than HTTPS. Users can also find themselves on hostile networks where HTTP links are rewritten to strip out HTTPS. In other cases, someone may follow an outdated link that still points to an HTTP URL.

Beyond user behavior, some web servers are still configured to listen on HTTP ports and redirect traffic, a practice that leaves users exposed to attacks like session-cookie hijacking and other man-in-the-middle exploits. HTTP Strict Transport Security addresses all of these scenarios by ensuring the secure connection is enforced at the browser level, before any insecure request can be made.

How HSTS worksLink to heading

When a user visits an HSTS-enabled website such as "https://test.com", the server responds with a Strict-Transport-Security header containing an HSTS directive. This directive signals to the browser that all future connections to that domain must be made over HTTPS. The header typically includes an expiration period and defines which domains the policy applies to. A standard example looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

This tells the browser to enforce HTTPS across all subdomains for one full year, effectively blocking access to any subdomain that only supports HTTP. The browser stores this instruction and honors it for the entire duration specified in the header.

On any subsequent visit, the browser automatically upgrades HTTP requests to HTTPS before they reach the server, regardless of whether the user clicked an HTTP link or typed a subdomain without a protocol. Using the same example, if the browser encounters "http://test-sub.com", it silently rewrites it to "https://test-sub.com" without ever making an unencrypted request to the server.

Once the max-age period expires, the browser stops enforcing the HTTPS upgrade and resumes normal behavior for HTTP requests. The policy is refreshed each time the browser receives the Strict-Transport-Security header from the server again.

HSTS PreloadingLink to heading

The Strict-Transport-Security header supports an optional preload parameter, which signals that the domain owner wants the site included in or removed from the HTTP Strict Transport Security preload list.

HSTS only protects a user after their browser has received the header at least once through a successful HTTPS connection. That means first-time visitors are still vulnerable during the initial request, since the browser has no prior record of the HSTS policy. 

If a user is redirected from HTTP to HTTPS on the first visit, there is a window of exposure before the policy is applied, and if they never land on the parent domain directly, they may never receive an includeSubDomains directive at all.

To address this, major browsers including Chrome, Firefox, Safari, Opera, and Edge maintain an HSTS preload list. Domains on this list have HSTS enforcement built directly into the browser, meaning the policy is applied from the very first visit with no prior connection required.

Because the list is shared across browsers, a single submission can result in consistent HTTPS enforcement across multiple platforms. In Chrome, the Chrome security team maintains a submission form where domain owners can request inclusion in the preload list. Once accepted, the domain is hardcoded into Chrome as HTTPS-only.

To qualify for preloading, a domain must meet a specific set of requirements. HTTPS must be fully enabled across the root domain and all subdomains, and the Strict-Transport-Security header must include both a long max-age value and the preload directive.

During startup or an update, the browser fetches the latest version of the preload list and applies the corresponding HTTP Strict Transport Security policies immediately. Users connecting to preloaded domains are automatically served over HTTPS without any redirects or additional steps. 

Browser vendors continuously maintain the preload list by adding newly submitted domains that meet the requirements and removing those that no longer qualify or have opted out of the policy.

>>> Learn more: What is HTTP/3? A guide to enabling HTTP/3 for your website

Common threats addressed by HSTSLink to heading

Here are the most common threats that HSTS can help minimize.

Man-in-the-Middle (MITM) attacksLink to heading

HTTP connections do not encrypt data in transit, which makes it relatively straightforward for attackers to intercept requests and redirect users to malicious websites. This is precisely how man-in-the-middle attacks operate. HSTS mitigates this risk by ensuring that all browser requests are sent over encrypted HTTPS connections, preventing unauthorized parties from eavesdropping on or tampering with the communication.

Cookie HijackingLink to heading

Cookie hijacking happens when an attacker gains unauthorized access to a user's session cookies and uses them to impersonate that user. By enforcing HTTPS, HTTP Strict Transport Security ensures that session cookies are only transmitted over encrypted connections, significantly reducing the risk of this type of attack.

Protocol downgrade attacksLink to heading

This is a variant of the man-in-the-middle attack in which an attacker forces a user's browser to communicate over the weaker HTTP protocol instead of HTTPS. Because HSTS-enabled websites instruct the browser to use HTTPS for all subsequent requests, protocol downgrading is blocked even when the user manually enters an HTTP URL.

Certificate-based MITM attacksLink to heading

Attackers can also conduct man-in-the-middle attacks by presenting a fraudulent certificate to users visiting unsecured websites, with the goal of tricking them into trusting it. HSTS addresses this by preventing users from bypassing the browser's invalid certificate warning, stopping the attack before the user can make a potentially compromising decision.

Advantages of HSTSLink to heading

Improves web securityLink to heading

HSTS protects against a wide range of cyberattacks by ensuring that communication between clients and servers cannot be exploited through weak or unencrypted protocols. Enforcing HTTPS across all connections guarantees a secure channel for users and prevents attackers from intercepting or manipulating sensitive data such as session cookies and personal information.

Improved performanceLink to heading

When a user revisits an HSTS-enabled website, the browser does not need to re-validate the HTTP Strict Transport Security header on every request. Instead, it caches the header locally and applies the policy automatically, which reduces unnecessary overhead and can contribute to faster page load times.

Enhances user experience and trustLink to heading

Knowing that a website consistently enforces HTTPS through HSTS helps build user confidence in the security of that site. It also streamlines the browsing experience by removing the need for repeated SSL certificate validations during navigation, making the overall interaction smoother and more reliable.

Simplifies implementationLink to heading

Features such as HSTS preloading allow security policies to be applied consistently across all visits, independent of user behavior or their familiarity with the website's security setup. This reduces the administrative burden of relying solely on server-side redirects to enforce secure connections.

Limitations of HSTSLink to heading

Understanding the limitations of HTTP Strict Transport Security is just as important as knowing its benefits, as additional security measures may be needed to address the gaps it leaves.

• Privacy issues: When a browser visits an HSTS-enabled website, the policy can tag that browser with identifiable information derived from HSTS super cookies. This information can persist even when the user is browsing in private or incognito mode and can potentially be used to track users across different domains.
• Ineffective against DNS-based attacks: Attackers can use DNS spoofing techniques that rely on deceptive or fabricated domain names not included in the HSTS preload list. In these cases, HSTS offers no protection, as it has no mechanism to validate the legitimacy of domain name resolution.
• Ineffective against TLS attacks: Even with the HSTS preload list in place, HSTS does not protect against sophisticated attacks that target the TLS protocol itself, such as the BEAST or CRIME attacks. These vulnerabilities exist at a lower level of the security stack, beyond the scope of what HSTS is designed to handle.

Deploying HSTS on your web serverLink to heading

Step 1: Prepare your website for HTTPSLink to heading

Before enabling HSTS, make sure your website is fully functional over HTTPS:

• Obtain an SSL/TLS certificate from a trusted Certificate Authority such as SSL.com.
• Install the certificate on your web server.
• Configure your web server to serve content over HTTPS.
• Update all internal links to use HTTPS.
• Ensure that all external resources such as scripts and images are also loaded over HTTPS.

Step 2: Add the HSTS HeaderLink to heading

Start by adding the HTTP Strict Transport Security header with a short max-age value to test your configuration. Using max-age=300 (5 minutes) is a safe starting point before committing to a longer duration.

Apache

Add the following to your .htaccess file or server configuration:

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

Nginx

Add this line inside your server block in the Nginx configuration file:

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

IIS

For IIS, add the header through your web.config file:

xml
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Strict-Transport-Security" value="max-age=300; includeSubDomains; preload"/>
    </customHeaders>
  </httpProtocol>
</system.webServer>

Step 3: Test your HSTS implementationLink to heading

Once the header is in place, verifying the implementation is an important step before moving forward.

Using online tools: Services such as SSL Labs or Security Headers can confirm that the HSTS header is present and correctly configured.

Using browser developer tools:

• Open your website in a browser such as Chrome or Firefox.
• Press F12 to open the developer tools panel.
• Navigate to the Network tab.
• Refresh the page and select the initial request, which is typically your domain name.
• Look for the Strict-Transport-Security header in the Headers section to confirm it is being sent by the server.

Testing HTTPS enforcement:

• Try accessing your website using http:// and verify that it redirects correctly to https://.
• If you included the includeSubDomains directive, check that your subdomains are also being served securely.

Step 4: Increase the max-age valueLink to heading

After confirming that your HTTP Strict Transport Security implementation is working correctly with the short max-age value, increase the duration to a longer period such as one year (max-age=31536000).

Apache

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

Nginx

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

IIS

xml
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload"/>
    </customHeaders>
  </httpProtocol>
</system.webServer>

Step 5: Consider HSTS preloadingLink to heading

HSTS preloading adds an extra layer of protection by registering your domain on a hardcoded list of HSTS-supported websites built directly into major browsers. To submit your website for preloading:

• Ensure that your HSTS header includes the preload directive.
• Visit the HSTS Preload List Submission website.
• Enter your domain name and follow the submission process.

Note: Preloading is a strong security measure but can be difficult to reverse. Make sure your website is fully prepared for long-term HTTPS-only access before submitting your domain.

ConclusionLink to heading

HTTP Strict Transport Security is one of those security controls that quietly does a lot of heavy lifting. It closes the gap that SSL certificates and server-side redirects leave open, ensures every connection to your site is encrypted from the first request, and removes the browser behaviors that attackers routinely exploit. 

Implementing it correctly, takes less time than most people expect and delivers lasting protection. If your site is already running on HTTPS, adding HSTS is the logical next step toward a security setup that actually holds up under real-world conditions.

>>> Worried that HTTPS alone still leaves your WordPress site exposed? Activate W7SFW now and block threats before they reach your server.