- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 25 Nov 2009 15:12:19 -0800
- To: Tyler Close <tyler.close@gmail.com>
- Cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Nov 25, 2009, at 1:34 PM, Tyler Close wrote: > On Wed, Nov 25, 2009 at 1:25 PM, Adam Barth <w3c@adambarth.com> wrote: >> Whether one can send an HTTP PUT request to another origin depends on >> which API is being used. For the HTML Form element, the HTML >> specification contains this requirement. For the XMLHttpRequest API, >> the XMLHttpRequest specification contains the requirement. >> >> The essence of the same-origin policy is the "sameness" relation >> (i.e., how to compute it on URLs), which is what's contained in that >> draft. The details of what actions are restricted to the "same" >> origin are details best left to the application layer. > > My impression is that the undefined consensus understanding of the > Same Origin Policy incorporates the rule that no API (not just a > specific API, such as HTML form) can allow a cross-origin PUT, unless > the target resource has somehow opted out of SOP protection. This > rule, and others like it, are the source of much of the complexity in > CORS. These rules are not left to the application layer. CORS attempts to follow this rule: the only requests that can be issued cross-origin without explicit opt-in (preflight) are ones that could have been issued by following a link or submitting a form. It is assumed that just the ability to issue such a request (without reading the response) would not create new vulnerabilities. This is the reason custom methods and headers are not allowed without preflight. It is also the reason Content-Type is restricted to a small whitelist without preflight. In some cases this boundary may be drawn in an overly conservative way; but preflight is always available as an alternative. In general this is probably a reasonable rule for new networking facilities. I'm not sure it's the right answer for every networking API; for example, WebSocket has a different way to avoid exposing existing servers, namely requiring a very specific handshake sequence. But the general principle is to avoid exposing servers to requests that are not already possible, unless there is explicit opt-in or the source of the request is same-origin with the server (which is taken as presumptive opt-in). Regards, Maciej
Received on Wednesday, 25 November 2009 23:12:53 UTC