On Mon, Dec 21, 2009 at 5:35 PM, Adam Barth <w...@adambarth.com> wrote:
> On Mon, Dec 21, 2009 at 5:17 PM, Kenton Varda <ken...@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.