W3C home > Mailing lists > Public > www-tag@w3.org > February 2016

Re: Comment on minutes ## With Credentials flag etc

From: Yves Lafon <ylafon@w3.org>
Date: Mon, 1 Feb 2016 11:55:01 +0100
Cc: Mark Nottingham <mnot@mnot.net>, Tim Berners-Lee <timbl@w3.org>, Public TAG List <www-tag@w3.org>
Message-Id: <C4519473-AC36-4032-9E3C-0833CFB3A31C@w3.org>
To: Jonas Sicking <jonas@sicking.cc>

> On 21 Jan 2016, at 02:24, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Jan 18, 2016 at 3:27 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> ... or at least the motivations behind the decisions explained. It's pretty impenetrable now, and even security folks don't profess to know all of the details behind CORS any more.
> I'm bummed to hear that aspects of CORS is still confusing even to the
> TAG. This stuff likely needs to get documented someplace. I had hoped
> that it'd get documented in the spec, but maybe there's a better
> place?


> Q: Why does CORS not allow "Access-control-allow-origin: *" together
> with withCredentials=true?
> A: It was felt that this was too big of a foot gun.
> CORS was designed not long after Adobe had added the crossdomain.xml
> feature to Flash Player. The crossdomain.xml feature allows webserver
> administrators to easily indicate that the server contains resources
> that should be loadable from other origins. The feature only allowed
> "normal" requests, i.e. requests similar to ones that CORS makes when
> withCredentials=true.
> When crossdomain.xml was released many websites opted in allowing data
> to be read from other websites in order to share some public data that
> was hosted on the server. Unfortunately they forgot that some other
> URLs on the server served sensitive user data. The result was that
> relatively quickly after the release of the crossdomain.xml multiple
> websites leaked sensitive user data.
> You could argue that the problem was that crossdomain.xml was
> different since it is a per-server configuration file, whereas CORS
> uses per-URL headers. Hence CORS would be less prone to server
> administrators accidentally opting in to sharing on URLs that server
> user sensitive data.
> However in practice many (most?) popular web servers allow adding
> configuration files which add static http headers to all URLs under a
> given directory. So in practice on many servers it would have been
> just as easy to make the same mistake with CORS.

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. Thank you for clearing this (during the TAG discussion, the
origin of this decision was not clear).

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.

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Monday, 1 February 2016 10:55:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:13 UTC