Missing HSTS (Strict-Transport-Security) Header
Last updated August 9, 2026.
What this finding means
Your site sends no Strict-Transport-Security instruction that a browser will act on. Browsers that have never visited before, or whose HSTS record for your domain has expired, have nothing telling them to skip plain HTTP — meaning every visit can begin as an insecure HTTP request before any redirect happens.
This finding covers three configurations, because a browser treats all three identically. The header may be absent altogether; it may be present with max-age=0, which RFC 6797 §6.1.1 defines as an instruction to delete any policy the browser already holds for your domain — the specification's own off switch, not a weak setting; or it may be present with no valid max-age at all, which is a required directive, so browsers ignore the header entirely. All three are reported as this one finding, with the same fix, because in all three the control is off.
Why it matters
Without HSTS, every visit starts as a plain HTTP request that your server then redirects to HTTPS. That first request is a window: an attacker on the same network (a coffee-shop Wi-Fi, a compromised router) can intercept it and strip the redirect, keeping the victim on HTTP indefinitely — a classic SSL-stripping attack. HSTS closes that window by making the browser skip HTTP entirely on repeat visits, and the `preload` directive lets you close it on the very first visit too, by getting the domain baked into browsers' shipped preload lists.
What Nivaronix checks
Nivaronix's security headers checker inspects the response headers your site sends and reports whether Strict-Transport-Security is present and in effect. Presence alone is not enough: the check reads the max-age directive, and treats a header that carries no valid one, or carries max-age=0, the same as a header that isn't there. This is a security misconfiguration check based on the header's presence and configuration — not a vulnerability scan, exploit attempt, or penetration test.
Any non-zero max-age passes. There is no minimum lifetime and no threshold above zero. A short max-age is a real, functioning policy for its lifetime, and starting at max-age=300 before raising it is exactly what the fix below and our HSTS guide tell you to do. A staged rollout is not penalised while it is in progress. Zero is the only value the specification itself defines as “off”, and it is the only value below which this finding is reported.
Evidence example
Example only, for illustration — not evidence from a live scan of any specific site.
HTTP/1.1 200 OK
(no Strict-Transport-Security header present)
# reported identically, because browsers act on neither:
Strict-Transport-Security: max-age=0
Strict-Transport-Security: includeSubDomains
# not reported — a short lifetime is still a working policy:
Strict-Transport-Security: max-age=300; includeSubDomainsHow to fix it
Nginx
add_header Strict-Transport-Security "max-age=300; includeSubDomains" always; # raise to 31536000, then add preload, once every subdomain is verified on HTTPSApache
# raise to 31536000, then add preload, once every subdomain is verified on HTTPS
Header always set Strict-Transport-Security "max-age=300; includeSubDomains"Cloudflare
SSL/TLS → Edge Certificates → enable "Always Use HTTPS" and the HSTS toggle (sets the header at the edge; review the max-age, subdomains and preload options in that panel before enabling preload).Verify the fix
Re-run a scan on your domain, or check manually with curl -sI https://your-domain.example, and confirm Strict-Transport-Security now appears in the response with the expected value.
FAQ
Why does this finding fire even if my site redirects HTTP to HTTPS?
A redirect and HSTS solve different problems. The redirect only takes effect after the browser has already sent a request — meaning the first request from any visitor who typed a bare domain, followed an old link, or hasn't visited before still goes out over plain HTTP first. HSTS is what removes that first insecure request; a redirect alone can't do that job.
Why does max-age=0 count as missing rather than as a weak setting?
RFC 6797 §6.1.1 defines max-age=0 as an explicit instruction telling the browser to delete any HSTS policy it already holds for the domain — it's the specification's own off switch, not a low but functioning value. A header with no valid max-age at all is ignored by browsers entirely for the same reason: the directive is required, so its absence makes the whole header inert.
Do I need a full year max-age to get real protection?
No — any non-zero max-age is a working policy for its lifetime, and this finding only fires below that. A short value like max-age=300 while confirming HTTPS works everywhere, raised to the standard one-year baseline afterward, is the recommended staged rollout, not a penalized interim state.
Is HSTS preload required to pass this check?
No — preload is optional and requires its own separate submission process plus a one-year max-age and includeSubDomains. This finding only checks whether the header is present with a non-zero max-age; preload is a further step beyond what clears this specific finding.
Standards reference
RFC 6797 — HTTP Strict Transport Security (HSTS). See the methodology page for exactly how this finding is scored.