4 ms·
My biggest gripe with CORS is how the destination site needs to opt into it for requests of every kind. For instance, by default a cross-origin XMLHttpRequest o
by LegionMammal978 2y ago
My biggest gripe with CORS is how the destination site needs to opt into it for requests of every kind. For instance, by default a cross-origin XMLHttpRequest or fetch() request will not include cookies, and if you ask it to include cookies, then the destination must include an Access-Control-Allow-Credentials header if you want the browser to allow it.
So that's all well and good, except for the part where even requests without cookies still need an explicit Access-Control-Allow-Origin in the response. As far as I am aware, the only attack vector this protects against is when the destination decides to release sensitive information solely based on the IP address of the source, and not based on its cookies or any other information not already accessible to JS. (Obviously, the biggest instance of this is in the case of local network addresses, but there are efforts to further restrict cross-origin requests to such addresses, using a separate header, Access-Control-Allow-Private-Network [0].)
I find this a shame, since it means that it's impossible to download most public data in a web app without proxying it through your own server, just because of this one edge case.
[0] https://github.com/WICG/private-network-access https://github.com/WICG/private-network-access
- seri4l 2y ago>it means that it's impossible to download public data from a web app without proxying it through your own server. Maybe with a subdomain that points to the target website IP? If it supports HTTP and doesn't check the host header it should be fine. That's pretty exceptional these days though. Edit: I just checked and a subdomain won't do it, it needs CORS as well.