Deno is a JavaScript, TypeScript, and WebAssembly runtime with secure defaults. When you send a request with the Authorization header to one domain, and the response asks to redirect to a different domain, Deno'sfetch() redirect handling creates a follow-up redirect request that keeps the original Authorization header, leaking its content to that second domain. This vulnerability is fixed in 2.1.2.

Affected: crates.io: deno_fetch, crates.io: deno

### Summary When you send a request with the `Authorization` header to one domain, and the response asks to redirect to a different domain, Deno's`fetch()` redirect handling creates a follow-up redirect request that keeps the original `Authorization` header, leaking its content to that second domain.

### Details

The [right behavior](https://fetch.spec.whatwg.org/#ref-for-cors-non-wildcard-request-header-name) would be to drop the `Authorization` header instead, in this scenario. The same is generally applied to `Cookie` and `Proxy-Authorization` headers, and is done for not only host changes, but also protocol/port changes. Generally referred to as "origin".

The [documentation](https://docs.deno.com/runtime/reference/web_platform_apis/#:~:text=Deno%20does%20not%20follow%20the,leaking%20authenticated%20data%20cross%20origin.) states: > Deno does not follow the same-origin policy, because the Deno user agent currently does not have the concept of origins, and it does not have a cookie jar. This means Deno **does not need** to protect against leaking authenticated data cross origin

### Reproduction ```ts const ac = new AbortController()

const server1 = Deno.serve({ port: 3001, signal: ac.signal }, (req) => { return new Response(null, { status: 302, headers: { 'location': 'http://localhost:3002/redirected' }, }) })

const server2 = Deno.serve({ port: 3002, signal: ac.signal }, (req) => { const body = JSON.stringify({ url: req.url, hasAuth:…