Every redirect hop is re-validated before it is taken
Pinning binds the original host only. Without this, a public host answering a redirect to a link-local metadata address walks straight past a guard that has already reported success.
The rule
- Each redirect target is validated on the same terms as the original URL, before the hop is taken, and a hop resolving into a private or reserved range is refused.
- Hops are re-validated, not refused: a redirect from one public host to another (a shortener, a canonical-host bounce, an upgrade to HTTPS) is still followed, so this is no change for workflows that are not being attacked.
- The residual window is stated rather than papered over: a hop's host is resolved for the check and resolved again for the request, so per-hop rebinding remains possible where the original request's pinning excludes it.
What it means
Pinning the original host protects only the first hop. Left there, a public host that answers with a redirect could send the connection anywhere on its next request, past a guard that already reported success once. Re-validating every hop closes that gap without closing off ordinary redirects: a hop that lands on another public host — a link shortener, a canonical-host bounce — is still followed. Only a hop that resolves into a private or reserved range is refused, at the moment it would be taken, not the destination it started from.
Example
A first hop lands on a different public host:
"https://target.example.com/real""arrived"The same request shape, redirected instead into a private or reserved address, never reaches that second response — the hop is refused before it is taken.