Security & Anonymity

HSTS Explained – HTTP Strict Transport Security Setup

HSTS tells browsers to ALWAYS connect to your site over HTTPS - what it does, the right setup for a small site vs a critical one, and the preload list.

5 min read

You’ve enabled HTTPS and redirected HTTP to HTTPS in .htaccess. Good — but there’s still a tiny window of attack: the very first request a visitor sends might go via HTTP (before the redirect). On hostile networks, that first request can be intercepted. HSTS (HTTP Strict Transport Security) closes that gap by telling browsers “for this domain, always use HTTPS — never even try HTTP.” This guide explains what HSTS does, how to enable it safely, and the preload list mechanism.

What HSTS does

Your server sends a header:

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

Browser receives this on a successful HTTPS response. From then on (for max-age seconds), every time the user types yourdomain.com or clicks a link, browser automatically converts to https:// before sending the request. No HTTP request ever leaves the browser.

Protects against:

  • Man-in-the-middle attacks downgrading HTTPS to HTTP.
  • SSL strip attacks on public Wi-Fi.
  • Cookie hijacking via HTTP requests.
  • Browser fallback to HTTP if HTTPS certificate breaks.

The headers explained

max-age

Seconds the browser remembers HSTS for this domain. Common values:

  • 0 — Disables HSTS for the domain (useful to revert).
  • 86400 (1 day) — Cautious testing value.
  • 2592000 (30 days) — Reasonable for confidence-building.
  • 31536000 (1 year) — Standard production value.
  • 63072000 (2 years) — Required for HSTS preload list.

includeSubDomains

Applies HSTS to all subdomains too (mail.yourdomain.com, blog.yourdomain.com, etc.). Highly recommended once you’re sure all subdomains support HTTPS.

preload

Marks domain as candidate for browser preload list (hardcoded in Chrome, Firefox, Safari source code). Even first-ever request to your domain uses HTTPS.

Enabling on iWebVault — .htaccess

Add to your .htaccess:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" "expr=%{HTTPS} == 'on'"
</IfModule>

The “expr=%{HTTPS} == ‘on'” ensures HSTS only sent on actual HTTPS responses (not HTTP requests pre-redirect).

For LiteSpeed (default on iWebVault), the syntax works identically.

Cautious rollout

HSTS is powerful — and irreversible during max-age period. Once a browser caches HSTS for your domain, it will refuse HTTP for max-age seconds. If you accidentally break HTTPS, every visitor with cached HSTS gets a hard error and can’t access your site.

Safe rollout pattern:

  1. Verify HTTPS works on ALL pages, ALL subdomains.
  2. Verify AutoSSL renewal is working reliably.
  3. Start with short max-age (300 seconds — 5 minutes). Deploy. Test.
  4. Increase to max-age=86400 (1 day). Wait several days. Watch for issues.
  5. Increase to max-age=2592000 (30 days). Wait a few weeks.
  6. Increase to max-age=31536000 (1 year). Production state.
  7. If applying for preload list — increase to max-age=63072000 (2 years) and add ?preload directive.

Verifying HSTS is active

  • Browser DevTools → Network → click any page request → Headers tab → Response Headers → look for “strict-transport-security.”
  • chrome://net-internals/#hsts — see Chrome’s HSTS list. Type your domain. Should show static_sts_domain (or dynamic_sts_domain).
  • Online checker: hstspreload.org — tests current header and preload eligibility.

The preload list

Browsers ship with a list of domains that ALWAYS use HTTPS, never tried over HTTP even on first request. Getting on the list means perfect HTTPS-only enforcement from day one for every browser user.

Requirements:

  • Valid HTTPS certificate.
  • HTTP redirects to HTTPS.
  • All subdomains support HTTPS.
  • HSTS header: max-age ≥ 31536000, includeSubDomains, preload.
  • Submit at hstspreload.org.

The catch

Removal from preload list takes months. If you submit and later decide HTTPS isn’t right for your domain, you’re stuck for a long time. Only submit if you’re 100% committed to HTTPS-only forever.

Most small sites don’t need preload list. Standard HSTS header covers 99.9% of scenarios.

When NOT to enable HSTS

  • Development sites with self-signed certificates. Browser will refuse access to localhost copies.
  • You’re not sure HTTPS will keep working. If certificate renewal fails, visitors locked out for max-age seconds.
  • Sites with HTTP-only subdomains. includeSubDomains breaks those.
  • Sites still in HTTP/HTTPS transition. Wait until all mixed-content issues fixed.

Disabling HSTS

Set max-age=0:

Header always set Strict-Transport-Security "max-age=0"

Browsers that receive this immediately forget HSTS for your domain. New ones connecting won’t get the directive.

For preload list: must apply for removal at hstspreload.org. Months-long process.

HSTS with Cloudflare

If your site is behind Cloudflare proxy:

  1. Cloudflare dashboard → SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS).
  2. Enable, configure max-age, includeSubDomains, preload.
  3. Cloudflare handles HSTS header at edge.

Simpler than .htaccess approach because Cloudflare’s UI explains implications.

Other security headers worth setting

While editing .htaccess for HSTS, add these common security headers:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" "expr=%{HTTPS} == 'on'"
    Header set X-Content-Type-Options "nosniff"
    Header set X-Frame-Options "SAMEORIGIN"
    Header set Referrer-Policy "strict-origin-when-cross-origin"
    Header set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

For Content Security Policy specifically, see CSP guide.

Common questions

“My visitors complain they can’t reach my site after I changed something.” If you broke HTTPS and HSTS is active, visitors with cached HSTS get hard errors. Fix HTTPS immediately. Clearing HSTS in browsers requires user action.

“How do I test what happens if my certificate breaks?” Don’t — in production. Build a staging copy, break certificate intentionally, observe. Then fix and verify recovery.

“My site’s on a subdomain. HSTS on parent affects me?” If parent has includeSubDomains, yes. Verify your subdomain has HTTPS first.

“Will HSTS hurt my SEO?” No. Google supports HTTPS-only sites; HSTS demonstrates security commitment.

“What if a user clears their browser cache — does HSTS reset?” Yes — HSTS info is part of browser state. Clearing site data clears HSTS too. Preload list still applies though.

What’s next

HSTS is a small header with big security benefit — once you’re confident HTTPS will keep working, enabling it eliminates the most common attack vector against HTTPS sites. Cautious rollout (short max-age, increase gradually) catches mistakes early. For sites handling sensitive data, HSTS is no longer optional; for casual sites, it’s still a good practice with minimal downside once correctly configured.

Was this helpful?