The chain moves between hostnames
Updated
What this check looks for
Visitors are handed from one hostname to another along the way. That is normal — it is how www redirects and content networks work — and it is recorded here so the rest of the report makes sense.
Why it matters
Nothing is wrong. It is worth knowing because the security headers, cookies and certificate this report grades belong to the final host, not the one you typed, and because HSTS applies per host — a chain that leaves a hostname before it sends its HSTS header never protects that hostname.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- HTTP
- Module
- Http redirects
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Make each host in the chain send its own HSTS header before handing the visitor on.
HSTS protects only the host that sent it, so a host the chain leaves before sending one stays reachable over plain HTTP.
Redirect plain HTTP to HTTPS on the same host first, then to the other host.
Send
Strict-Transport-Securityon every HTTPS response in the chain, redirects included, and addincludeSubDomainson the bare domain once every subdomain serves HTTPS.If a cookie set on the first host has to reach the second, give it a
Domainattribute that covers both; otherwise set it on the final host.
How to confirm it worked
curl -sIL http://‹host›/ | grep -iE '^(http|location|strict-transport-security)' — expect an HSTS header on each HTTPS response
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.
Technical detail
‹detail›
Two consequences are worth checking. First, an HSTS header on the final host does not cover the host the visitor started at, so the first hop should send its own. Second, cookies set before the hop are not sent to the new host unless their Domain covers it.
The usual shape is canonicalisation — example.com to www.example.com or the reverse — or a hand-off to a separate sign-in, shop or CDN host. Each host in the chain is its own HSTS host and its own cookie scope, and the order of the hops decides what a visitor's browser learns on the way through.
The order that protects every host is to upgrade to HTTPS on the same host first, send Strict-Transport-Security on that HTTPS response, and only then move to the other host. http://example.com to https://example.com to https://www.example.com is two redirects, within the three our chain check accepts, and it is the shape the HSTS preload list requires of a bare domain. Jumping from http://example.com straight to https://www.example.com saves a hop, but the bare name then never sends an HSTS header a browser will accept, so the next visit typed without www starts over plain HTTP again. An includeSubDomains header served on the bare domain also covers www and every other subdomain.
To trace the chain yourself, curl -sIL http://‹host›/ prints each response's status, Location and headers in order; check that every HTTPS response before the last hop carries the HSTS header.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.