[cap-talk] Open Review of the CORS Specification

[Adam Barth]

On Mon, Oct 12, 2009 at 11:20 PM, David-Sarah Hopwood
<david-sarah at jacaranda.org> wrote:
> 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*;

The pre-flight request is meant to prevent attackers from being about
to issue requests they cannot currently issue.

> 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.

You're right that a form submission can be sent cross-origin, but a
form submission cannot attach custom headers.  There are many web
sites that rely on custom headers to distinguish same-origin requests
from cross-origin requests.  For example, the Google Web Toolkit uses
this mechanism.  If we were to forgo the pre-flight request in these
cases, we would create vulnerabilities in legacy servers.  Note that
we're not making a value judgement about whether those servers are
well or poorly designed.  They exist and we're obligated to protect
them.

> The example of DELETE is spurious --
> who cares about DELETE enough to introduce this extra message for all
> HTTP methods?

I've personally built web applications that rely on the fact that
DELETE requests cannot be sent cross-origin.  If I've done it, I'm
sure that other folks have done it too.  One of the design constraints
for CORS is that we cannot introduce vulnerabilities into legacy
servers that are unaware of the CORS protocol.

Adam