Preventing SSL Stripping with HTTP Strict Transport Security (HSTS)

Most developers assume that serving a website over HTTPS and implementing a 301 redirect from HTTP is sufficient for security. While this approach encrypts the connection for legitimate users, it leaves a dangerous window of opportunity for attackers during the initial handshake. This vulnerability exists because browsers typically default to an unencrypted HTTP request when a user types a domain name directly into the address bar.

During this first unencrypted request, an attacker positioned between the user and the server can perform a technique known as SSL stripping. The attacker intercepts the HTTP request and establishes a secure connection to the real server on behalf of the user. However, they continue to communicate with the user's browser over plain HTTP, effectively removing the security layer without the user noticing.

The fundamental problem is that the browser has no prior knowledge that the site expects a secure connection. Standard server-side redirects happen after the first request has already been sent over the wire in plaintext. By the time the server tells the browser to upgrade to a secure connection, the attacker may have already modified the response to prevent the upgrade from ever occurring.

The primary goal of HSTS is to shift the responsibility of secure connection enforcement from the server-side redirect to the browser itself, effectively neutralizing the window for protocol downgrade attacks.

HTTP Strict Transport Security is implemented via a single response header sent by the server over a secure connection. This header instructs the browser to automatically convert all future attempts to access the site via HTTP into HTTPS requests locally. This transformation happens within the browser's networking stack before any data is sent over the network.

The header is only honored if it is received over a valid HTTPS connection with no certificate errors. If a browser receives an HSTS header over plain HTTP, it must ignore it to prevent attackers from injecting malicious security policies. Once stored, the browser will refuse to connect to the site via HTTP for the duration specified in the policy.

1server {
2    listen 443 ssl http2;
3    server_name production.example.com;
4
5    # The 'always' parameter ensures the header is sent even on error pages
6    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
7
8    # Rest of your SSL and application configuration
9}

1const express = require('express');
2const helmet = require('helmet');
3const app = express();
4
5// Use Helmet to set secure headers including HSTS
6app.use(helmet.hsts({
7  maxAge: 31536000, // One year in seconds
8  includeSubDomains: true,
9  preload: true
10}));
11
12app.listen(443);

While HSTS protects subsequent visits, the very first visit to a site remains vulnerable because the browser has not yet received the header. To solve this bootstrap problem, major browser vendors maintain a hardcoded HSTS Preload List. This list is bundled directly into the browser's source code, ensuring that the browser knows to use HTTPS even before the first connection is made.

Getting on this list requires meeting several strict technical criteria, including a minimum max-age and the inclusion of all subdomains. Once a domain is on the preload list, it is effectively impossible for a user to access the site over plain HTTP in any modern browser. This provides the highest possible level of protection against network interception.

• A valid SSL certificate must be served for the apex domain and all subdomains.
• All HTTP traffic must be redirected to HTTPS on the same host before any cross-domain redirects.
• The max-age must be at least 31536000 seconds (one year).
• The includeSubDomains and preload directives must both be present in the header.

Implementation of HSTS should never be done in a single step with a long duration. Instead, developers should use a phased rollout strategy to identify hidden dependencies that might break under strict HTTPS enforcement. Start with a very short max-age, such as five minutes, and monitor site health and user reports for any connection issues.

Gradually increase the duration over several weeks, moving from minutes to hours, then days, and eventually months. This incremental approach allows you to verify that all subdomains and internal services are correctly configured with valid certificates. If something breaks, the impact is limited to the short duration of the current policy cache.

One common pitfall is forgetting about internal development environments that might use unencrypted connections on the same domain hierarchy. If your production site sets includeSubDomains, developers working on local versions like dev.example.com will find their browsers refusing to connect without a valid certificate. It is often better to use a dedicated domain for development to avoid these conflicts.