HSTS header does not contain includeSubDomains
The observed HSTS header did not contain ShipReady's recognised includeSubDomains directive.
Why it matters
includeSubDomains changes the scope of an HSTS policy. Its absence is a policy-review signal: extending a policy can be useful when the domain estate is ready, but it needs a deliberate deployment decision.
How ShipReady detects it
What it inspects
ShipReady reads the non-empty Strict-Transport-Security header from a successfully fetched, readable, same-site content-serving 2xx final response.
What triggers a finding
The rule triggers when the observed HSTS value does not contain includeSubDomains after case normalization and removal of spaces.
What the evidence shows
The HSTS header observed by ShipReady did not contain the scanner's recognised includeSubDomains directive.
Limits of this check
ShipReady does not inventory subdomains, test their HTTPS readiness, inspect cookie Domain scopes, or determine whether HSTS inheritance is appropriate. It checks the final fetched response rather than redirect hops or every route; this finding is not evidence of an inherent vulnerability.
How to fix it
Review the subdomain estate first
List the subdomains that would inherit the policy and confirm their intended HTTPS behavior, including internal and staging hosts, before enabling includeSubDomains.
Enable inheritance only when appropriate
If the review supports it, add includeSubDomains to the HSTS policy and deploy it through the layer that sends the final response header.
How to verify the change
Inspect the deployed HSTS value
Inspect representative final response headers after deployment and validate the relevant subdomain behavior separately.
Expected: The HSTS header reflects the chosen policy scope, and any affected subdomains are ready for that choice.