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

The criteria for adding new features to the web should be to either
* Enable things that were simply impossible before.
* Make it significantly easier to do something which is commonly done but that is complex to do today.

But in both cases a requirement is: Don't make it too easy to have security issues. Generally speaking, it should be easier to do the safe thing, than to do the unsafe thing.

I don't think any of the features discussed lately matches the first bullet.

I think supporting `Access-Control-Allow-Headers: *` and `Access-Control-Allow-Methods: *` matches the second criteria. But if we allow them for requests with credentials it fails the "too easy to have security issues" test. This is especially true if we add something like #210.

Adding features to credential-less requests is generally quite safe since it essentially only allows things that curl already allows, and so exposes the website to very little risk.

In order to add features for requests with credentials, I think it needs to be shown that web developers will understand the implications of those features and not opt in to the wrong thing.

Adobe's crossdomain.xml feature was a good example of what happens if we make it too easy to opt in to lots of functionality for requests with credentials. After that feature was released, lots of websites ended up with security problems. I have not heard anything similar for CORS.



---
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-201032859