dotvitals

HSTS does not cover subdomains

LowConfirmedweb.security-headers.hsts-no-subdomains

What this check looks for

The always-use-HTTPS instruction applies to this hostname only. Subdomains can still be reached over plain HTTP.

Why it matters

An attacker does not need your main site — a plaintext subdomain is enough to set a cookie that your main site then trusts, because cookies are shared across a domain in ways the browser's origin rules are not.

When the check passes, your report says: “HSTS covers subdomains as well as this hostname”.

What it costs your score

When this check fails it removes 5 points from your Web security score, before the status, confidence and repeat multipliers are applied. Web security carries a weight of 8 in the overall score.

It shares the web-security.hsts family ceiling of 28 points: however many findings that family produces, together they cannot remove more than that from Web security. One underlying problem showing up in several places is still one problem.

Severity
low
Default confidence
confirmed
Status when triggered
warn
Deduction
5 points
Family cap
web-security.hsts · 28
Category
Web security
Module
Web security headers
Fix owned by
user
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Add includeSubDomains — after auditing every subdomain.

A plaintext subdomain can be used to attack the main site through shared cookies.

  1. List every subdomain, including internal tools and old staging names still in DNS.

  2. Confirm each serves a valid certificate over HTTPS.

  3. Add includeSubDomains at a short max-age first, then raise it.

How to confirm it worked

  • curl -sSI https://‹host›/ | grep -i includeSubDomains

The configuration to publish
Strict-Transport-Security: max-age=31536000; includeSubDomains

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Apache
<IfModule mod_headers.c>
	Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>
Caddy
header {
	Strict-Transport-Security "max-age=31536000; includeSubDomains"
}
Cloudflare
Rules → Overview → Create rule → Response Header Transform Rule → Set static → Strict-Transport-Security = max-age=31536000; includeSubDomains
(Dashboard path as at 2026-09; Cloudflare reorganised these pages and may again.)

  • The always flag matters: without it nginx omits the header on error responses, which are exactly the ones an attacker aims for. Note also that any add_header in a location block discards every add_header inherited from the server block.

  • Shown because the response identified Apache. Put it in the virtual host rather than .htaccess: .htaccess is re-read on every request, and Header always set there runs too late for responses the server generates itself.

  • A Transform Rule adds the header at Cloudflare's edge, so it applies only to responses that reach visitors through Cloudflare. An origin that is reachable directly — by IP, or through a DNS record that is not proxied — still serves the response measured here without it. Setting it at the origin covers both paths.

Technical detail

The header has no includeSubDomains directive. RFC 6797 §6.1.2 extends the policy to every subdomain when it is present. The caution is real: every subdomain, including ones you may have forgotten, must serve a valid certificate before you enable it, because after that browsers will refuse to load any that does not.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the web security headers checkerBuild the fix

Other web security headers checks