Defaults.Exposed › Fixes › HSTS (Strict-Transport-Security)

How to fix HSTS (Strict-Transport-Security)

HSTS is a one-line instruction your website gives every browser: 'always come back to me over the secure, encrypted connection — never the insecure one.' Without it, your padlock can be quietly stripped away on shared WiFi, and the very first visit to your site is exposed.

Bottom line for your business: Having HTTPS (the padlock) is not the same as enforcing it. Without HSTS, an attacker on the same WiFi as your customer can silently downgrade the connection to plain, unencrypted HTTP — capturing logins, card details and form data while the customer sees nothing wrong. Your SSL certificate, which you may be paying for, is bypassed. The fix is free and takes about 15 minutes for whoever runs your site.

What this can cost you

• Customers on cafe, hotel, airport or conference WiFi can have their connection to your site silently downgraded and their data read — with no warning on their screen.
• You paid for HTTPS and have the padlock, but without HSTS attackers can simply route around it; the certificate gives a false sense of safety.
• The very first visit to your site (before any redirect to HTTPS) is the weak point attackers target — HSTS is what closes it for every return visit.
• A security questionnaire, cyber-insurance form or enterprise buyer's checklist flags 'no HSTS' and stalls the deal until it's fixed.
• Set the value wrong (too short) and you get the worst of both worlds: it looks configured but provides almost no real protection.

Why it matters. HTTPS protects a connection once it is encrypted — but it does not force browsers to use it. Attackers exploit that gap with 'SSL stripping': on any shared network they quietly keep the visitor on insecure HTTP, reading everything. HSTS tells the browser to refuse plain HTTP for your domain entirely, for a long time, so the gap closes after the first visit. It is a single response header, free to add, and on our scoring it is worth real points because a missing or too-short value leaves every visitor on public WiFi exposed.

What this is, in plain words

You almost certainly have HTTPS — the little padlock in the browser bar. Good. But here is the part almost nobody is told: having HTTPS is not the same as forcing it.

HTTPS makes a connection encrypted once the browser decides to use it. HSTS — short for HTTP Strict Transport Security — is the instruction that makes the browser always use it. It’s a single, invisible line your website sends to every visitor that says, in effect:

“From now on, for my domain, only ever talk to me over the secure connection. Never the insecure one. Don’t even try.”

The browser remembers that and obeys it for as long as you tell it to — typically a year. After a visitor’s first secure visit, their browser will simply refuse to load your site over plain, unencrypted HTTP, even if something tries to force it.

Without HSTS, that “always use the secure version” rule doesn’t exist — and attackers know exactly how to exploit the gap.

What this can cost you

These are realistic, everyday scenarios. We never name a real business; these are illustrations of how the gap gets used.

1. The coffee-shop checkout. A customer opens your shop on cafe WiFi and goes to check out. An attacker on the same network runs a free, well-known tool that keeps the customer on plain HTTP instead of HTTPS. The customer sees what looks like your normal site — no warning, no broken padlock in the spot they’d glance — and types their card details. The attacker reads every keystroke. Your SSL certificate did nothing, because the connection was never allowed to become secure in the first place.

2. The travelling employee. A staff member logs into your admin panel or webmail from a hotel or airport. The same downgrade trick captures their username and password. Now the attacker has a way into your business — not because your password policy was weak, but because the login page was reachable over insecure HTTP.

3. The deal that stalls. A larger customer sends you their standard security questionnaire before signing. One line asks: “Does your website enforce HTTPS via HSTS?” Your IT contact has to answer “no,” and the procurement process pauses while you scramble to fix a free, 15-minute setting that now looks like a red flag in front of a buyer.

4. The cyber-insurance or compliance check. An insurer’s scan, or an auditor reviewing your data-protection posture, flags the missing header. Encryption of personal data is an explicit expectation under data-protection rules (GDPR Article 32), and “we have a certificate but don’t enforce it” is a weak place to be standing.

5. The false sense of security. You’re paying for SSL, the padlock shows, and everyone assumes the site is safe. It mostly is — until a customer is on a shared network, which is exactly when they’re most vulnerable and least likely to notice anything wrong.

The through-line: the cost isn’t abstract. It’s a real customer’s card or login, captured at the worst possible moment, with no alarm going off.

What it actually is

When a browser asks your website for a page, your server sends back the page plus some invisible “headers” — extra instructions the browser reads but the visitor never sees. HSTS is one of those headers:

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

Three parts matter:

• max-age — how long (in seconds) the browser should remember to force HTTPS. 31536000 is one year. This is the heart of it: too short and it barely helps.
• includeSubDomains — extend the rule to every subdomain (shop., app., mail. and so on), not just your main address.
• preload — opt your domain into a master list built into browsers, so protection applies even on a visitor’s very first request, before they’ve ever seen your site.

Why “the first visit” matters

HSTS has one inherent limitation: a browser only obeys the rule after it has seen the header at least once. So a brand-new visitor’s very first connection is still a tiny window of exposure. Two things narrow it: an HTTP-to-HTTPS redirect (which gets them onto the secure version fast) and preload (which removes the window entirely). That’s why a complete setup pairs HSTS with a proper redirect.

What “good” looks like — and how it’s scored

Our check reads your live header and grades the max-age:

So a header that exists but is set to a few minutes is treated as a fail — it looks configured but isn’t doing the job. Aim for one year. The check also notes whether includeSubDomains and preload are present.

How to fix it (free, ~15 minutes)

Hand this section to whoever runs your website — your IT person, web developer, or hosting support. The fix is free. It is a single header, or a toggle in your hosting platform. There is nothing to buy.

One important ordering rule first: HSTS is sticky — once enabled, browsers will refuse plain HTTP for your domain for the full max-age. So confirm HTTPS works correctly on your main site and every subdomain before turning it on broadly. The safe path is: test with a short value → confirm nothing breaks → raise to one year.

Step 1 — Make sure HTTPS already works everywhere

Visit your site and key subdomains over https:// and confirm they load cleanly with a valid certificate. Also confirm plain http:// requests redirect to https://. (If they don’t, fix the HTTP-to-HTTPS redirect first — HSTS assumes it’s in place.)

Step 2 — Add the header (pick your platform)

Cloudflare (or similar CDN): This is the easiest. Go to SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) and enable it. Set Max-Age to 6 months or 12 months, and enable “Apply HSTS policy to subdomains” once you’re sure all subdomains are on HTTPS.

Nginx: add inside your HTTPS server block:

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

Apache: ensure mod_headers is enabled, then add to your HTTPS virtual host:

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

Microsoft IIS: add to web.config inside <customHeaders>:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

Google Workspace / Microsoft 365 note: these power your email, not your website hosting — HSTS is set wherever your public website actually lives (your CDN, web server or site builder), not in Workspace/365 admin. If your site is on a builder like Squarespace, Wix or Shopify, HSTS is usually handled for you; check their SSL/security settings if our check flags it.

Step 3 — Test small, then commit

Start with max-age=300 (5 minutes). Confirm the site still loads perfectly everywhere. Then raise it to max-age=31536000 (one year). That’s the full-marks setting.

Step 4 (optional, gold standard) — preload

Once you’re confident and have run a one-year header with includeSubDomains for a while, you can submit your domain at hstspreload.org to be baked into browsers. This closes the first-visit window entirely. Treat it as a deliberate commitment — removing a domain from the list is slow.

Common mistakes

• Setting max-age too short. A value of a few minutes or hours looks configured but provides almost no protection — and our check treats anything under a day as a fail. Use a year.
• Turning on includeSubDomains before subdomains are HTTPS-ready. If a subdomain isn’t fully on HTTPS, the sticky rule can make it unreachable for visitors. Get every subdomain onto HTTPS first.
• Adding HSTS but having no HTTP-to-HTTPS redirect. HSTS assumes visitors reach the secure version; without the redirect, the first visit is needlessly exposed. Fix both together.
• Jumping straight to preload to “be thorough.” Preload is hard to undo. Earn it gradually after a stable one-year header — don’t rush it.
• Assuming the padlock means you’re covered. The padlock and HSTS are different things. You can have a perfect certificate and still fail this check.

FAQ