W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: HTTP access control confusion

From: Dirk Pranke <dpranke@chromium.org>
Date: Fri, 30 Jul 2010 14:57:48 -0700
Message-ID: <AANLkTikt-rsFNg9D99mdkquZ0NYX8xkUrT9btgQL0pcy@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Douglas Beck <dbeck@mail.ucf.edu>, public-webapps@w3.org, Jared <jslang@mail.ucf.edu>
On Fri, Jul 30, 2010 at 1:45 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Jul 29, 2010 at 8:10 AM, Douglas Beck <dbeck@mail.ucf.edu> wrote:
>> I have recently read through:
>> https://developer.mozilla.org/En/HTTP_access_control
>> https://wiki.mozilla.org/Security/Origin
>>
>> I've discussed what I've read and learned with my coworkers and there's been
>> some confusion.  I understand and appreciate the need for a security policy
>> that allows for cross-site https requests.  I do not understand how
>> Access-Control-Allow-Origin addresses usability and security concerns.
>>
>> The basis of our confusion:
>> I create domain-a.com and I want to make an ajax request to domain-b.com.  A
>> preflight request is made to domain-b, domain-b responds with if it is safe
>> to send the request.
>>
>> Does it not make more sense for me (the author of domain-a) to define the
>> security policy of my website?  I know each and every request that should be
>> made on my site and can define a list of all acceptable content sources.  If
>> the preflight request is made to domain-a (not domain-b) then the content
>> author is the source of authority.
>>
>> A more functional example (and the source of my curiosity), I work for the
>> University of Central Florida.  I am currently working on a subdomain that
>> wants to pull from the main .edu TLD.  The university has yet to define an
>> Access-Control header policy, so my subdomain is unable to read what's
>> available on the main .edu website.
>>
>> Additionally, if I am working with authorized content, it would be useful
>> for me to define/limit where cross-site requests can be made.  It seems
>> backwards that an external source can define a security policy that effects
>> the usability of my content.
>
> As the author of your site, you *already* have complete control over
> where cross-site requests can be made.  If you don't want to make a
> particular cross-site request, *just don't make that request*.
>
> On the other hand, the content source doesn't have that kind of
> control.  They can't prevent you from making requests to them that
> they don't want, or allow requests that they like.  That's where the
> same-origin policy (default deny all such requests) and CORS
> (selectively allow certain requests) comes in.
>
> I suppose you might be thinking of a situation where you are allowing
> untrusted users to add content to your site, and you only want them to
> be able to link to specific other sites.  Same-origin restrictions do
> part of this for you automatically.  Most of the rest should be
> handled by you in the first place - if untrusted users are doing XHRs,
> you've got bigger problems.
>
> ~TJ

Untrusted users (or untrusted content) will probably be doing XHRs
quite frequently (this is almost
the definition of a widget). You just need to ensure that they're
running inside a sandboxed iframe
(or something like Caja) so that they can't exploit your site as easily.

-- Dirk
Received on Friday, 30 July 2010 21:58:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT