IncludeSubDomains

What IncludeSubDomains changes in HSTS

IncludeSubDomains turns a parent-domain HSTS policy into a broader trust boundary. Once a browser has seen the header, it will treat every subdomain as HTTPS-only as well, which reduces downgrade and SSL-stripping exposure across the namespace. That makes it a stronger security control, but also a stricter commitment for every host you operate under that domain.

In practice, the directive matters because subdomains are often managed unevenly. A parent site may be fully prepared for HTTPS, while older applications, internal tools, or delegated subdomains still depend on plain HTTP or lack a valid certificate. If those hosts cannot serve HTTPS reliably, the browser policy can break access rather than merely harden it.

Why it is safer than host-by-host HSTS

Without IncludeSubDomains, HSTS only protects the exact host that sent the header. That leaves sibling and child hosts exposed to first-visit downgrade attacks, mixed configuration, or accidental HTTP reuse. Extending the policy to subdomains creates a more consistent security baseline and reduces the chance that one overlooked hostname becomes the weak link in the domain.

The main security gain is consistency. Users do not have to remember which subdomain is “secure enough,” and attackers have fewer opportunities to steer traffic to an HTTP endpoint or intercept a connection before HTTPS is enforced. The directive is especially valuable for public web estates with many application fronts, redirects, and legacy aliases.

Coverage assumptions and operational dependencies

IncludeSubDomains is only safe when the whole namespace is ready for HTTPS. That means every reachable subdomain needs a valid certificate, correct hostname coverage, and a working TLS configuration. It also means teams need visibility into forgotten DNS records, staging hosts, third-party subdomains, and services created outside the main web team’s control.

NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because the control model reinforces secure configuration, access discipline, and integrity protection for web-facing services. In the same way, HSTS should be treated as part of a broader configuration baseline, not a stand-alone header toggle.

Failure conditions and recovery considerations

The biggest failure mode is assuming the policy is harmless because the parent site works. If a subdomain still responds only over HTTP, or if its certificate chain is broken, browsers will refuse the fallback path. That can turn a security hardening step into an outage for users, automation, or dependent services that still reach that hostname.

Recovery is often slower than expected because browsers cache HSTS state. If you enable the directive too early, you may need to repair certificates, restore HTTPS, or reissue configuration before affected clients can reconnect normally. The safest rollout pattern is to verify every known subdomain first, then enable the directive once the full estate is proven ready.

Practitioner Guidance

Why practitioners should care: IncludeSubDomains is one of those settings that strengthens security only when the organisation has already done the inventory work. Treat it as a domain-level commitment, not a cosmetic header value. If you cannot confidently account for every subdomain, you should delay deployment rather than risk breaking legitimate traffic.

What to watch for: Focus on forgotten DNS entries, legacy applications, wildcard certificate gaps, and subdomains owned by other teams or vendors. These are the places where HTTP dependence and certificate misalignment usually hide. A careful rollout should validate both external reachability and certificate coverage before the parent domain advertises the policy.