[whatwg/fetch] What would be the downside of respecing `Access-Control-Allow-Origin: *` even when the `Origin` header is not sent? (#680)

I recently noticed an interesting peculiarity with the default behavior of the `crossorigin` attribute on `img` tags, which lead me down [a long rabbithole](https://www.reddit.com/r/programming/comments/82j5or/while_trying_to_diagnose_an_unusual_cors_issue_i/dvbwnnd/?context=3) reading through the HTML Standard and Fetch spec.

Right now, the Fetch spec [has this note](https://fetch.spec.whatwg.org/#cors-protocol) regarding the CORS protocol: 

> It needs to be an opt-in mechanism to prevent leaking data from responses behind a firewall (intranets).

As I understand it, the "data" being referred to here is the "Origin" header, which is always sent with CORS requests but not necessarily with non-CORS requests.

This makes sense, but does require developers to be aware of the opt-in and [can result in unexpected behavior](https://www.reddit.com/r/programming/comments/82j5or/while_trying_to_diagnose_an_unusual_cors_issue_i/dvahw3a/) if they're not.

With that in mind, I'd like to explore what downsides there might be in changing the spec to allow CORS requests to optionally be sent without setting the `Origin` header on the request (aside from, of course, the effort required to change the spec and associated browser implementations).

Would there be any security, privacy, or compatibility drawbacks to this? I can't really think of any myself.

-- 
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/680

Received on Wednesday, 7 March 2018 19:06:43 UTC