W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: HTTPbis and the Same Origin Policy

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 25 Nov 2009 15:12:19 -0800
Cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <EC6DD822-F1FF-40D3-81E3-8D3F9FB2EC4B@apple.com>
To: Tyler Close <tyler.close@gmail.com>

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  

Received on Wednesday, 25 November 2009 23:12:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC