Security headers in the wild: what's actually deployed
HSTS is a response header that tells browsers to always reach a site over HTTPS, rewriting insecure links and treating certificate errors as fatal rather than clickable warnings. It guards against session-hijacking on unencrypted networks, DNS spoofing, and mixed-content mistakes, but does not defend against phishing or malware already on a device. Missing or misconfigured headers account for 1 of 1 findings across scanned sites.
Why this matters: headers are how a site tells the browser what to enforce
A security header is an instruction from server to browser. The browser has no way to know, on its own, that a site should always be reached over HTTPS — the site has to say so, in the response, as defined by HTTP Strict Transport Security (HSTS).
A host that wants this protection returns a Strict-Transport-Security response header over a secure connection; a browser that has seen this header rewrites any future insecure ("http") link to that host into a secure one before making the request, and it treats any certificate error or warning on that host as fatal rather than something the user can click through (RFC 6797).
The threat this closes is not theoretical. On a shared or open wireless network, a passive attacker can use freely available sniffing tools to capture unencrypted session cookies and hijack a logged-in session; widely distributed tools built for exactly this purpose (Firesheep is the RFC's example) made this attack routine rather than exotic (RFC 6797). HSTS is aimed squarely at that scenario, plus active attacks such as DNS spoofing or a fake access point, and at simple deployment mistakes like a login page that loads one stylesheet over plain HTTP (RFC 6797).
It's worth being precise about what HSTS does not cover. The RFC is explicit that it is not a defense against phishing — a fake site on a different domain — nor against malware already running on the user's machine; it protects the integrity of a session's transport, not the user's judgment or the security of their device (RFC 6797).
Headers can cover more than one domain
A site operator can also declare that the policy applies to an entire subtree of a domain, not just the one host that sent the header — for example, a policy set at example.com can also govern bar.foo.example.com (RFC 6797). The RFC is equally explicit about the limits of that reach: a subdomain cannot set policy for its parent, and one subdomain cannot set policy for a sibling subdomain (RFC 6797). That asymmetry matters operationally — securing a subdomain does not secure the rest of the domain, and vice versa.
The numbers
Across completed scans, 1 of the non-informational findings that check produced — out of 1 such findings — were about a header that was missing or set incorrectly, rather than confirmation that a recommended header was present. Separately, looking at scan reliability generally, 15 of the passive checks attempted actually completed, out of 16 attempted, which is the denominator behind any finding-based statistic we report from a scan.
Frequently asked questions
What does the Strict-Transport-Security header actually do?
It tells a browser that already knows about a host to convert any insecure link to that host into a secure one before the request goes out, and to stop — rather than warn and allow through — if a secure connection attempt hits a certificate error (RFC 6797).
If my site only serves HTTPS, do I still need HSTS?
Yes.
Does HSTS protect against phishing?
No.
Can I set one HSTS policy for my whole domain and its subdomains?
Yes, with limits.
How do I find out which headers my own site is sending?
The fastest way is to run a check that reads the actual response headers your server sends and compares them against what's recommended.
Where to start
Sources
---
_Researched with AI assistance from a live passive security scan run by NEL (scan eph_mso819ss_s), which was not retained; citing 1 external source; 12 factual claims were extracted and checked against their sources (12 of 12 verified); each verification step was independently recorded and signed by Vitna, which attests that the check ran and what its verdict was — not that the underlying claim is true (records be8d93f5-fa31-4543-8ec0-45b3fff2fcb4, 8e409880-ad15-41b1-ad42-253090807c71, aa2f2e76-8cfd-4e8b-8715-c9297666fe20, +76 more, verify at https://vitna.costrinity.xyz/api/evidence/verify); reviewed and approved by admin:nelnationale before publishing; published by NEL Professionals with no individual byline._
Get up to 100 scans or unlimited lifetime access starting at $15.
View Plans →Comments (0)
No comments yet. Be the first to comment!