- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 30 Jul 2010 16:45:38 -0400
- To: Douglas Beck <dbeck@mail.ucf.edu>
- CC: public-webapps@w3.org, Jared <jslang@mail.ucf.edu>
On 7/29/10 11:10 AM, Douglas Beck wrote: > 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 think the source of your confusion is that HTTP access control in the above scenario is protecting domain-b from domain-a. It's not protecting domain-a. Thus the security policy needs to be defined by domain-b. > I know each and every request that > should be made on my site and can define a list of all acceptable > content sources. The point here is that domain-a should not be able to get data from domain-b using the user's credentials that it wouldn't be able to get otherwise. No one here is trying to protect domain-a from getting the "wrong" data or something. > 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. Unfortunately, there's no obvious way to distinguish your situation from an attack on the main .edu website trying to get unauthorized information from it... > Additionally, if I am working with authorized content, it would be > useful for me to define/limit where cross-site requests can be made. This is legitimate useful use-case. The proposed technology for handling it is http://people.mozilla.com/~bsterne/content-security-policy/details.html (see the "xhr-src" directive). > It seems backwards that an external source can define a security policy > that effects the usability of my content. Here's an illustration of what HTTP access control is supposed to prevent. A user visits your website. You do an XHR to a bankofamerica.com URL on the off chance that the user is a Bank of America customer and is currently logged in. If this XHR were allowed you would at the very least be able to read information about the user's account, and depending on the setup of the bankofamerica.com site may be able to do things like transfer money. _That_ is the threat HTTP access control is meant to mitigate. While it might be convenient if you could show the user information about their bank account on your site in some circumstances, that's something the bank (or ideally the user, but that's harder to set up) needs to opt into. Hope that helps, Boris
Received on Friday, 30 July 2010 20:46:13 UTC