HTTP access control confusion
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. I sincerely appreciate any time you can give explaining the policy. Thank you for all the great work that's been done. Sincerely, Douglas Beck -- Douglas Beck Web Communications | 407.823.1699
Re: HTTP access control confusion
On Thu, Jul 29, 2010 at 8:10 AM, Douglas Beck db...@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
Re: HTTP access control confusion
On Fri, Jul 30, 2010 at 1:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Jul 29, 2010 at 8:10 AM, Douglas Beck db...@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
