W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

From: Kenton Varda <kenton@google.com>
Date: Mon, 21 Dec 2009 17:48:42 -0800
Message-ID: <4112ecad0912211748h34150493of5fc356835cc7dc5@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Ian Hickson <ian@hixie.ch>, Tyler Close <tyler.close@gmail.com>, public-webapps <public-webapps@w3.org>
On Mon, Dec 21, 2009 at 5:35 PM, Adam Barth <w3c@adambarth.com> wrote:

> On Mon, Dec 21, 2009 at 5:17 PM, Kenton Varda <kenton@google.com> wrote:
> > The problem we're getting at is that CORS is being presented as a
> security
> > mechanism, when in fact it does not provide security.  Yes, CORS is
> > absolutely easier to use than UM in some cases -- I don't think anyone is
> > going to dispute that.  The problem is that the security it provides in
> > those cases simply doesn't exist unless you can ensure that no resource
> on
> > *any* of your allowed origins can be tricked into fetching your
> "protected"
> > resource for a third party.  In practice this will be nearly impossible
> to
> > ensure except in the most simple cases.
>
> Why isn't this a big problem today for normal XMLHttpRequest?  Normal
> XMLHttpRequest is just like a CORS deployment in which every server
> has a policy of allowing its own origin.
>

It *is* a problem today with XMLHttpRequest.  This is, for example, one
reason why we cannot host arbitrary HTML documents uploaded by users on
google.com -- a rather large inconvenience!  If it were feasible, we'd be
arguing for removing this ability from XMLHttpRequest.  However, removing a
feature that exists is generally not possible; better to avoid adding it in
the first place.

With CORS, the problems would be worse, because now you not only have to
ensure that your own server is trust-worthy and free of CSRF, but also the
servers of everyone you allow to access your resource.  Problems are likely
to multiply exponentially.
Received on Tuesday, 22 December 2009 01:49:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT