I think this rather applies to API clients which can handle that differently. A quick test for python's shows that all headers are redirect regardless: reque

I think this rather applies to API clients which can handle that differently. A quick test for python's shows that all headers are redirect regardless: requests.request("GET", "http://localhost/redirect-to?url=http%3A%2F%2Fhttpbin.org%2Fget", headers={"x-foo": "bar", "Cookies": "abc=dcv;"}).json() { "args": {}, "headers": { "Accept": "*/*", "Accept-Encoding": "gzip, deflate", "Cookies": "abc=dcv;", "Host": "httpbin.org", "User-Agent": "python-requests/2.22.0", "X-Amzn-Trace-Id": "Root=1-5e6bebe1-cd6e71729a818015a06aa7cb", "X-Foo": "bar" }, "origin": "91.58.8.128", "url": "http://httpbin.org/get" } I'm running a local copy of httpbin on localhost, so python's request should not send sensitive headers for redirects but it does. Golang is a bit more explicit about it's http client behavior: > • when forwarding sensitive headers like "Authorization", "WWW-Authenticate", and "Cookie" to untrusted targets. These headers will be ignored when following a redirect to a domain that is not a subdomain match or exact match of the initial domain. For example, a redirect from "foo.com" to either "foo.com" or "sub.foo.com" will forward the sensitive headers, but a redirect to "bar.com" will not. https://golang.org/pkg/net/http/#Client https://golang.org/pkg/net/http/#Client Though this might also cause problems if you are using sensitive non standard headers such as X-Token for token authentication, etc. So while you could probably mitigate this vulnerability on some clients, you are trusting the server to only redirect you to trusted URLs which is not the case here.