Why Your Website Sends No Health Header, and What That Allows

Reading a scanner result honestly

Security scanners flag a missing header and present it in the same visual register as a remote code execution flaw. It is not the same thing, and treating it that way produces bad prioritisation.

A missing header is an absence of defence in depth. It does not create a vulnerability on its own. It means that if some other weakness is found and exploited, one additional layer that would have blocked the attack is not present.

The correct question is not “is this failing a test” but “what specifically becomes possible that would not otherwise be”. For each header below, that is what the answer is.

The specific risk of no HSTS

HSTS — Strict-Transport-Security — tells a browser to refuse to make plain HTTP requests to your domain for a stated period, before any request is made. The critical property is before: it does not rely on the server receiving a request and redirecting.

Without it, the first request to your site is a plain HTTP request, and it happens before your server has any opportunity to influence it. This leaves a window for an attacker on the network path between you and the site.

The downgrade attack. An attacker on the same network — public Wi-Fi is the standard example — intercepts that first plaintext request, responds with a message of their own before your server ever responds, and the user never reaches your site. The classic version injects a script into the page. If the session is then established over HTTPS, the injected script rides along for the whole session.

Request-URL leakage. Even where an attacker cannot modify anything, plaintext HTTP reveals the full URL of every request. URLs leak more than people expect: search terms, session tokens in query strings, and the identity of which pages a visitor read.

Both risks are specific, real, and eliminated by HSTS. But note what HSTS does not do: it does nothing for a first visit to a domain that has never been visited before. Preloading solves that by baking the policy into the browser itself, at the cost of an effectively permanent commitment.

The order that matters

Serve valid HTTPS first. Everything else is meaningless before this. The failure mode to avoid is enabling HSTS on a site whose certificate is broken for some visitors, which converts a recoverable warning into an unreachable site.

Redirect HTTP to HTTPS. This stops the wrong-protocol request from reaching content, and it catches the majority of first visits. It is weaker than HSTS because the redirect itself travels in plaintext and can be intercepted — which is precisely the attack HSTS closes.

Verify HTTPS works everywhere. Check the bare domain, the www variant, every subdomain, your API paths, and your error pages. This is the step people skip, and a certificate that fails on one hostname is the usual reason a site loses all traffic when HSTS is enabled.

Add HSTS with a short max-age. A few hundred seconds, then a day. Watch access logs for plain HTTP requests continuing to arrive from somewhere unexpected — usually a monitoring service, an old client application, or an internal integration that has not been updated.

Raise it. Once nothing breaks, six months, then a year.

Consider preloading separately. Preload is a one-way door for browsers that have opted in. There is a submission list, removal is not guaranteed, and a domain that has ever been on it is hard to get off. Decide it on its own merits rather than as the last step of a routine sequence.

Other headers, in rough priority order

Content-Security-Policy is the most powerful and the most likely to break a site when deployed carelessly. It restricts where scripts may be loaded from, which directly limits what an injected script can do. Start with a report-only policy and read the violations before enforcing. Note the practical tension: a strict CSP that forbids inline styles is incompatible with many component libraries and content systems. A policy with 'unsafe-inline' in the style-src directive still delivers most of the benefit for style-based injection, because script execution is the target.

X-Content-Type-Options: nosniff prevents the browser from interpreting a declared type differently from what the server sends. One header, no meaningful downside, add it.

Referrer-Policy controls what is sent in the Referer header. The default on older browsers leaks full URLs, including query strings, to every third party a page links to. strict-origin-when-cross-origin is a sensible default: full URLs to your own origin, origin only elsewhere.

Permissions-Policy restricts which device features a page may use — camera, microphone, geolocation. If your site uses none of them, a restrictive policy costs nothing.

X-Frame-Options and the frame-ancestors CSP directive prevent your pages being framed. Relevant if you serve anything that could be used as a phishing target, since a framed official-looking page is a classic credential-harvesting technique.

What none of this protects against

Worth stating, because header lists invite the belief that the site is now secure:

They do not fix an application vulnerability. SQL injection, broken access control and authentication flaws are unaffected by every header above.

They do not stop a server-side compromise. If the host is breached, headers are irrelevant.

They do not protect the origin from an attacker with a valid certificate for your domain. That is why certificate transparency and monitoring registrations matter alongside headers.

And they do not protect users from their own compromised devices, which is the most common way credentials are stolen.

A practical way to check your own site

Start with the response headers for your own domain over both protocols, then examine the configuration.

Look at the header list the server returns. If Strict-Transport-Security is absent, that is the first finding. Then test whether plain HTTP returns content or redirects. A site that serves 200 OK over plain HTTP with no redirect is the more serious version of this problem, because the downgrade window is not merely unmitigated but actively being used.

Two things make these checks more reliable than a scanner’s summary:

Check over plain HTTP, not just HTTPS. Several headers only have meaning over HTTPS, and a scan performed exclusively over TLS will not tell you whether the redirect works.

Test the error pages. Some hosting configurations lose security headers on 404 responses, which is how a scanner declares a site clean while the pages that matter are unprotected.

Why this often shows up on sites that are otherwise fine

A recurring pattern: the site was built, TLS was configured, and the site worked. Nobody needed to think about HSTS, because in practice browsers upgrade automatically — Chrome and Firefox have preloaded HSTS for some domains and many users type a URL without a scheme, which defaults to HTTPS.

So the site functions fine, passes casual inspection, and has had the missing header for years. This is why it usually surfaces in a formal audit rather than as an incident.

The exposure is real but bounded, and it is one of the cheapest items on a security backlog to resolve properly.