- From: Dirk Pranke <dpranke@chromium.org>
- Date: Fri, 30 Jul 2010 14:57:48 -0700
- 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 UTC