[whatwg/xhr] Non-simple CORS requests on redirect (#255)

I have run into this specific scenario where if a XHR initiates a CORS request with special headers ( Eg- Access-Control-Allow-Headers’: authorization, content-type), and response to it is a redirect (say 303) to a URI which is still cross-origin, XHR will initiate a new pre-flight request to this new URI. The issue is that if this third party origin happy reflects all the ‘Access-Control-Allow-Headers’ values, and has ‘Access-Control-Allow-Origin’ as a wildcard, the final request will also sent with our custom authorization and content-type headers to this third party origin.

In short,

mainapp.com -> `(Need auth header for API)` api.app.com -> `(Redirects, but also sends Auth header, thus leaking to CDN)` -> CDN (anotherorigin.com)

This behavior is that this is similar to a configuring a **wildcard Access-Control-Allow-Origin, while allowing credentials.** There is a good reason this is disallowed. But in this case, instead of the credentials being passed as Cookies, we can pass an auth header? 


#The original CORS spec (https://www.w3.org/TR/cors/) disallowed this specific scenario (sec 7.1.5) :

```
This is the actual request. Apply the make a request steps and observe the request rules below while making the request.
If the response has an HTTP status code of 301, 302, 303, 307, or 308
Apply the cache and network error steps.
```

I understand that we can use fetch() with controlling redirects for a “fix”, but it would probably make the code deployment-specific. Open for discussion.

P.S. - This was observed on the latest versions of both FF and Chrome, will consider opening an issue with them as well for discussion.

-- 
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/xhr/issues/255