Re: [whatwg/fetch] Drop developer-controlled Authorization header on cross-origin redirects (#944)

I encountered an issue with this behaviour that struck me as counter-intuitive, but reading through this issue I can see why it occurred. As @paulmillar states above, consider a use-case of an API requiring authentication that if successful redirects to a cloud resource using a pre-signed URL (e.g. S3, GCP, other bucket storage) derived from server-side secrets:

The following _looks_ like it should restrict the `Authorization` header to the same origin:

```javascript
// Execute a fetch against a same-origin API endpoint
fetch('/api', {
  credentials: 'same-origin',
  headers: {
    'Authorization': 'Bearer a_secret_value'
  }
}).then(res => /* Do something with data from transparent redirect to cloud provider */)
```

In the case of S3 with a permissive CORS policy, the actual error returned is that only one authentication method can be used, i.e. S3 saw a signed URL and an Authorization header both of which could be valid in different circumstances, however the header in this case was only valid for the same origin API server.  If I block the `Authorization` header in the CORS preflight response, the request fails anyway because fetch still tries to send it.

As a developer, based on the semantics of `credentials: 'same-origin'`, I would not _expect_ my API token to be forwarded on to a different origin. I would also not _expect_ to have to configure a third party provider to reject my secret header.

I am also unable to manually handle this edge case by intercepting the redirect, based on the answers to Issue #763.

> If I may venture an opinion, "Atomic HTTP redirect handling" is a stated goal of Fetch, which places the onus on the API (and the web-browser implementations) to "do the right thing". The current behaviour for credentials: 'include' seems to go against perceived security best practice and would seem to have the possibility to break (seemingly) valid use-cases.

I would suggest that it is the behaviour for `credentials: 'same-origin'` that is against perceived best practice here, and does break my seemingly valid use-case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/944#issuecomment-840607956