HSTS: What It Is, How It Works, and How to Enable It

What is HSTS?

HTTP Strict Transport Security is a browser security policy delivered as an HTTP response header. When your server sends:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

…the browser records the policy in its internal HSTS store. For the next 63,072,000 seconds (two years), any time a user visits your domain — even if they type http:// — the browser silently rewrites the request to https:// before sending it. The HTTP request never actually goes out.

Without HSTS, the flow when a user types your domain looks like this:

HSTS removes the window between a user typing your URL and your server's redirect arriving. On an untrusted network — public Wi-Fi, a compromised router — that window is where SSL-stripping attacks live. (If you haven't set up that server-side redirect yet, do it first — our HTTP-to-HTTPS redirect guide has the exact config for Apache, Nginx, and IIS.)

How HSTS works

HSTS relies on a simple browser-side cache:

The first-visit problem (TOFU)

HSTS is a "Trust On First Use" (TOFU) mechanism. The very first HTTP request to your domain — before the browser has ever seen your HSTS header — still goes out unprotected. On most networks this is fine; a café network could theoretically intercept it.

The HSTS preload list solves this. Browsers ship with a hardcoded list of domains that must use HTTPS from the very first connection. If your domain is on it, there is no unprotected first hop.

The Strict-Transport-Security header explained

The full header has one required directive and two optional ones:

Strict-Transport-Security: max-age=<seconds>[; includeSubDomains][; preload]

Enable HSTS on Nginx

Add add_header inside your server {} block for port 443. The always parameter ensures the header is sent on every response code — 200, 301, 404, 500 — not just 2xx responses.

Phase 1: test with a short max-age

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example.com_fullchain.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # Start here: 5-minute policy for testing
    add_header Strict-Transport-Security "max-age=300" always;

    # ... rest of config ...
}

Visit your site, check the header is present (see Verifying your config), and confirm all pages load correctly over HTTPS.

Phase 2: production config

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example.com_fullchain.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # Production: 2-year policy, ready for preload submission
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

# HTTP → HTTPS redirect (no HSTS header here)
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

After editing, test the Nginx config and reload:

sudo nginx -t && sudo systemctl reload nginx

Already have Nginx SSL installed? See the full Nginx SSL installation guide for OCSP Stapling, HTTP/2, and cipher configuration.

Enable HSTS on Apache

Apache uses the mod_headers module for custom response headers. Verify it's enabled first:

sudo a2enmod headers
sudo systemctl restart apache2

Phase 1: test config

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/example.com_fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    # Phase 1: 5-minute policy for testing
    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=300"
    </IfModule>
</VirtualHost>

Phase 2: production config

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/example.com_fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    # Production: 2-year policy, preload-ready
    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security             "max-age=63072000; includeSubDomains; preload"
    </IfModule>
</VirtualHost>

# HTTP → HTTPS redirect (no HSTS here)
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

Test and reload:

sudo apachectl configtest && sudo systemctl reload apache2

Enable HSTS on IIS

IIS 10.0.17763 (Windows Server 2019) and later include native HSTS support via the site bindings dialog. Earlier IIS 10 versions and IIS 8/8.5 require a web.config custom header.

Option A: IIS Manager (Windows Server 2019/2022)

Option B: web.config (all IIS versions)

Add the header to your HTTPS site's web.config. Do not add it to the HTTP site used for redirects.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Strict-Transport-Security"
             value="max-age=63072000; includeSubDomains; preload" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

For a complete IIS SSL setup including URL Rewrite redirects and SNI binding, see the IIS 10 SSL installation guide.

The HSTS preload list

The HSTS preload list is a database of domains that browsers embed directly in their source code. Chrome, Firefox, Safari, and Edge all import it, which means listed domains get HTTPS-enforced from the very first connection — solving HSTS's first-visit limitation entirely.

As of early 2026, around 120,000 domains are on the Chrome preload list. Fewer than 36% of sites that send an HSTS header include the preload directive, so most HSTS-protected sites still have the first-visit gap.

Requirements for preload submission

All five requirements must be met before submitting:

How to submit

Once your header meets all requirements, visit hstspreload.org and enter your domain. The tool checks your live HSTS header against the requirements and queues a submission to the Chrome preload list. Timeline:

• Submission → Chrome Canary: days
• Chrome Canary → Chrome stable: weeks (one Chrome release cycle)
• Chrome → Firefox, Safari, Edge: weeks to months (each imports on their own schedule)

Pitfalls and gotchas

Verifying your HSTS config

1. Command line (curl)

The quickest check is a curl HEAD request — it bypasses any browser HSTS cache and shows you exactly what the server is sending:

curl -sI https://yourdomain.com | grep -i strict-transport-security

Expected output:

strict-transport-security: max-age=63072000; includeSubDomains; preload

2. Browser DevTools

Open DevTools → Network tab → click the document request → Response Headers. Look for strict-transport-security. Note: if the browser already has the domain in its HSTS cache, it may show an internal redirect and not hit the server at all — use curl to get the raw server response.

3. Chrome's HSTS internals

In Chrome, navigate to chrome://net-internals/#hsts. You can look up, delete, and manually add HSTS policies for specific domains — invaluable for testing without waiting for max-age to expire.

4. Preload eligibility check

The hstspreload.org tool checks whether your current header meets all five preload requirements and shows exactly which ones are failing. Use it before submitting.

Frequently asked questions