- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 1 Feb 2016 13:02:15 -0800
- To: Yves Lafon <ylafon@w3.org>
- Cc: Mark Nottingham <mnot@mnot.net>, Tim Berners-Lee <timbl@w3.org>, Public TAG List <www-tag@w3.org>
On Mon, Feb 1, 2016 at 2:55 AM, Yves Lafon <ylafon@w3.org> wrote: > One can find information like https://annevankesteren.nl/2012/12/cors-101 > stating that ‘*’ is always good… it is not because of what you just said, that is also why > people can get confused. I think we're both trying to say that it's safe to set for any URL accessible to the public internet. And that the reason that it's safe is because it only is honored for re requests that were made without cookies. > So to make it always work, you need to echo back the origin in Access-control-allow-origin, > it is very easy to do, and does not require a specific module for Apache. > The issue is that it can lead to careless administrators using that technique > “to make CORS work” and lead to the same issue that led to disallowing “*” with withCredentials. Indeed, it is quite easy to indiscriminately echo back the "Origin" request header in a "Access-control-allow-origin" response header. Thereby leaking private data. I don't know what we could have done on the spec or client side to lessen that risk though. If it is still possible to make such improvements without "breaking the web" I'm all ears. If it could only have been done when we originally designed the spec I'm bummed that we missed that opportunity. In theory we could design a new cross-origin protocol which includes such improvements and let callers opt in to it. However in practice I've never heard of people accidentally exposing undesired data due to the echoing you mention, so I doubt that it'd be worth designing a new protocol. / Jonas
Received on Monday, 1 February 2016 21:03:13 UTC