[cap-talk] Open Review of the CORS Specification
David-Sarah Hopwood
david-sarah at jacaranda.org
Mon Oct 12 23:20:22 PDT 2009
Adam Barth wrote:
> On Mon, Oct 12, 2009 at 9:41 PM, David-Sarah Hopwood
> <david-sarah at jacaranda.org> wrote:
>> The response always seems to be something equally as vague as:
>>
>>>> There were concerns that the CORS spec might not satisfy all the related
>>>> security issues; this is true, but we do believe that it solves a useful
>>>> set of cases, and doesn't introduce additional risk.
>>
>> which, without actually enumerating the kind of cases that are supposed to
>> be "solved", does not seem to me to be a substantive technical argument
>> in favour of CORS at all.
>
> The use cases are listed here:
>
> http://dev.w3.org/2006/waf/access-control/#use-cases
>
> I don't think we should beat up on Doug for not providing a technical
> argument.
I wasn't "beating up" specifically on Doug. The above document does not
provide a technical argument either. It just says:
# The main motivation behind Cross-Origin Resource Sharing was to remove
# the same origin restriction from various APIs so that resources can be
# shared among different origins (i.e. servers).
and then gives a short and incomplete list of APIs that currently use
same-origin.
When I read specifications (even non-normative sections of them), I at
least expect them to make a token effort to say things precisely. CORS
does not "remove the same origin restriction from various APIs"; what it
does is change the behaviour in the cross-origin case to something more
complicated -- and equally poorly motivated as far as I can see -- that
involves checking the alleged origin (the value of the Origin header)
against an ACL.
There is no attempt in the spec to explain why that would be a good idea,
given the known deficiencies of ACLs.
Putting aside other problems, it is unclear why the preflight request
is needed, given that the current same-origin policy does not (in most
cases) prevent a cross-origin request from being *made*; it only attempts
to prevent the response from being read. So the assertion in the "Design
Decision FAQ" section that 'The "permission to make the request" check is
performed because deployed servers do not expect such cross-origin
requests.' is nonsense, at least for GET requests and for POST requests
that could occur by form submission. The example of DELETE is spurious --
who cares about DELETE enough to introduce this extra message for all
HTTP methods?
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
More information about the cap-talk
mailing list