What is HSTS (HTTP Strict Transport Security)?
It's a one-line HTTP header that tells browsers: talk to this site over HTTPS only — and remember that, so no one can ever slip the connection back to plain HTTP. Flagged as missing on 21 of the 28 real sites in our audit corpus. Check in 30 seconds: open a terminal and run curl -sI https://yourdomain.com | grep -i strict. Empty output? Anyone on the same network as your visitor can strip your encryption.
The audit checks this on every page it crawls — up to 25 pages — and names every offender in the report.
The definition, in plain English
Strict-Transport-Security: max-age=31536000; includeSubDomains — that instructs browsers to refuse any non-HTTPS connection to your site for the duration of max-age, automatically upgrading http:// requests before they leave the browser. It closes the downgrade attack: an attacker on the same network (a coffee-shop Wi-Fi, a compromised router) intercepts the first plain-HTTP request and proxies it, keeping a clear channel to everything your visitor types. With HSTS set and cached, the browser never emits that vulnerable first HTTP request — the downgrade fails before it starts.
What our engine actually checks
Rule security/hsts · severity: warning · flagged on 21 of the 28 real audits behind our statistics page
The audit inspects your response headers for a Strict-Transport-Security header and sanity-checks its directives — a max-age long enough to matter, includeSubDomains where safe. A missing header is reported site-wide as a warning, since headers apply to every response equally.
In the corpus: 21 of 28 sites had no HSTS header — tied for third most common security finding with missing Subresource Integrity, behind the missing CSP and X-Frame-Options. The four travel together: sites that set security headers tend to set all of them, and the default for almost every host is to set none.
Why it matters, honestly sized
HTTPS without HSTS still has the gap the padlock doesn't show: a visitor's first request can be forced to plain HTTP (by typing yourdomain.com, following an old link, or an attacker rewriting a redirect), and that first exchange is unencrypted. SSL-stripping attacks live exactly there. HSTS removes the gap for every browser that has seen your header — which, after a max-age of months, is every returning visitor.
The invisible costs: security scanners and procurement checklists ask for HSTS specifically; payment-heavy sites increasingly need it (PCI DSS expects it); and browsers are moving toward treating HTTPS as assumed — the sites left behind are the ones flagged.
The fix, step by step
- Set the header at your host, CDN or server config — one line, no code changes:
Strict-Transport-Security: max-age=86400first. One day is a safe test window: if something breaks, it un-breaks itself in 24 hours. - Raise max-age once nothing broke to a year:
max-age=31536000; includeSubDomains.includeSubDomainscovers every subdomain — only add it once you're sure none of them needs plain HTTP (an internal tool, an old mail host). - Consider preloading. Submitting to hstspreload.org bakes your domain into the browser source itself, closing the very-first-visit gap too — but it's deliberately hard to undo, so only after a year-long max-age has run cleanly.
- Verify: re-run the curl check above and confirm the header appears; then visit
http://yourdomain.comand watch the address bar flip to https:// with no server round-trip doing the redirect.
What the £7.99 report checks — and what it can't
Everything here that can be checked from outside your site is mechanical, and mechanical is checkable. Full disclosure: some of it isn't, and we say which. The report is the full 21-category audit — what it costs and how it compares to doing it yourself are on their own pages.
The mechanical half
Checked across up to 25 pages per audit, with every offending page named and the exact fix spelled out.
- Strict-Transport-Security presence on your responses
- max-age and directive sanity — the short-max-age and missing-includeSubDomains traps
- the neighbouring headers in the same pass: CSP, X-Frame-Options, cookie flags
- mixed content: HTTP resources loaded on HTTPS pages
— Not ours to claim
What no report sold from outside your site can do:
- The report checks the header and its directives — it can't see whether every subdomain you own is safe for includeSubDomains (that's an inventory only you have), and it doesn't submit preload entries on your behalf. The fix list names the exact header value for your host.
Fair questions, straight answers
Doesn't my HTTPS certificate already cover this?
No — and this is the most common confusion. The certificate encrypts connections that use HTTPS; it does nothing to force connections to use HTTPS. A visitor who types yourdomain.com, or follows an http:// link, lands on plain HTTP first unless your server redirects — and that first plain exchange is exactly what HSTS eliminates. HTTPS is the lock; HSTS is the instruction to always use it.
What's the difference between the HTTPS redirect and HSTS?
A redirect happens on the server: the browser sends the request over plain HTTP, the server answers 'try HTTPS instead', and the browser retries. The first request still travelled unencrypted — readable and rewritable by anyone on the path. HSTS happens in the browser: it upgrades the request before it's ever sent. With HSTS cached, the plain-HTTP request simply never exists.
Will HSTS break my subdomains?
Only if one of them genuinely needs plain HTTP — with includeSubDomains set, every subdomain must serve HTTPS. Audit your subdomains first (blog., shop., staging., old internal tools), serve HTTPS on all of them, then add the directive. If you're unsure, set HSTS without includeSubDomains first and add it in a later pass.
Should I submit my site to the HSTS preload list?
It's the strongest form — preloaded domains refuse HTTP even on the very first visit, before your header has ever been seen. But inclusion is effectively permanent: removal takes months of ceremony across every browser release. The standard advice is to run a long max-age with includeSubDomains for at least a year with zero issues, then preload. Most small-business sites get full practical protection from the header alone.
Find out if your site really forces HTTPS.
Enter your URL and pay securely — your report PDF lands in your inbox in ~30 minutes,
with HSTS, CSP, clickjacking protection and cookie flags checked on every response.