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

Re: HTTP access control confusion

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 30 Jul 2010 13:45:42 -0700
Message-ID: <AANLkTinjTs1brSFw+gbTm1+B55hcJy6U61j_nrUQnX5X@mail.gmail.com>
To: Douglas Beck <dbeck@mail.ucf.edu>
Cc: public-webapps@w3.org, Jared <jslang@mail.ucf.edu>
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.

Received on Friday, 30 July 2010 20:46:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:10 UTC