Strict-Transport-Security header is absent from the fetched content response
The successfully fetched final content response did not include a non-empty Strict-Transport-Security header.
Why it matters
Strict-Transport-Security is a browser policy header. Its absence on an observed content response is a deployment configuration signal worth reviewing, without establishing how any browser currently treats the site.
How ShipReady detects it
What it inspects
ShipReady reads normalized response headers only after it has successfully fetched a readable, same-site content-serving 2xx final response.
What triggers a finding
The rule triggers when that final response has no Strict-Transport-Security header or its value is empty.
What the evidence shows
ShipReady did not receive a non-empty Strict-Transport-Security header on the fetched final content response.
Limits of this check
ShipReady inspects the final response, not redirect hops or every route, and has no separate HTTPS-scheme applicability guard for this rule. It does not inspect browser HSTS state or establish browser-effective HSTS, HTTP downgrade exposure, interception, or application-wide coverage.
How to fix it
Define and send an HSTS policy deliberately
Confirm the domain and deployment are ready for the intended HSTS policy, then configure the application, proxy, or CDN to send a non-empty Strict-Transport-Security header on the relevant HTTPS content responses.
Review the policy's deployment scope
Check representative production routes and the surrounding HTTPS deployment before increasing policy duration or inheritance settings.
How to verify the change
Inspect deployed final response headers
Request representative deployed content URLs and inspect their final response headers after redirects complete.
Expected: The intended content responses include the configured non-empty Strict-Transport-Security header.