Re: [fetch] Update Access-Control-Allow-Headers CORS response header to allow * (allow-all) (#251)

@craigfrancis I guess I'm fine with allowing `Access-Control-Allow-Headers: *` only on non-credentialed requests **initially**. I just want to know what criteria would be used to subsequently determine whether we should also allow it on credentialed requests in the future.

My concern is that if we don't allow it for credentialed request _now_, then it will _never_ be allowed for credentialed requests - in the absence of lots of user requests to add it (see my final paragraph below), no-one will ever get round to doing further research (or whatever) to decide whether to allow it. So it will sit there in the Dev queue as "another feature that we should consider", until it withers and dies... So I think it makes sense to make a final decision now to either allow it on all requests or only on non-credentialed requests, even if that might delay the implementation whilst more people weigh in on the security risks.

As everyone looking at this thread can figure out I feel strongly that we should allow it on **all requests** :). I think the benefit it provides, in terms of simplicity of use outweighs the possibility of security risk. Others disagree. Disagreement is good.

That being said, I see that @sicking has raised a specific concern about allowing it on credentialed requests:

> I think `Access-Control-Allow-Headers: *` would be quite easy to get wrong. Websites quite often today simply set a `x-xhr-request: true` header as a CSRF prevention mechanism. If such a website is able to opt in to `Access-Control-Allow-Headers: *` requests with credentials, they are immediately vulnerable to CSRF attacks.

I'm not sure I understand how allowing XHR to send any headers opens up to CSRF attacks  (@sicking can you elaborate for me?), but in any case, as he explicitly points out, many of the concerns that he has (indeed, that we all have) are 'just' about the ways in which incorrect implementation can open security holes - basically, we're concerned about footguns (feetgun?).

Personally, I think that allowing `Access-Control-Allow-Headers: *` for all requests should be enabled, as long as it is **clearly discussed** that there may be a possibility of security risk. Ideally with examples of things that should not be done. One of the benefits of WHATWG controlling the CORS spec rather than W3C is that the WHATWG documentation includes far more information - notes and discussion points - which are not included in the sparse W3C specs. I think we should make use of this ability to include _in the spec itself_ more information about implementations, good and bad. But that's just me.

Finally, do we have some feedback method from _users_ (as opposed to browser manufacturers) aside from raising issues here? For instance, I have made the contention that a relatively large percentage of requests are credentialed (even if it's still a minority). That's based on my experience, which is a) limited and b) different from other peoples. But do we have any idea of whether I'm correct, or completely mistaken? I guess it's not possible to poll users, but it would be interesting to know.

---
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/251#issuecomment-200943369