The server still needs to opt-in to allowing the web site to read the response or you get into trouble with firewalls. This functionality is already available in every modern browser.
Adam On Wed, Jun 15, 2011 at 10:15 AM, Charles Pritchard <[email protected]> wrote: > There have been a few requests for an XHR which does not expose session data > to the target. I believe IE9 has an interface for this; I know it's been > requested on chromium bug list. > > > > On Jun 15, 2011, at 9:18 AM, Boris Zbarsky <[email protected]> wrote: > >> On 6/15/11 6:43 AM, David Bruant wrote: >>> Could someone explain how running in a web browser justify such a >>> difference? For instance, could someone explain a threat particular to >>> cross-origin XHR in web browser? >> >> Off the top of my head: >> >> 1) XHR in the web browser sends the user's cookies, HTTP auth credentials, >> etc. with the request. Which means that if you're logged in to some site A, >> and cross-site XHR to that site is allowed from some other other site B, >> then B can access all the information you can access due to being logged in >> to site A. >> >> 2) XHR in the web browser gives (at the moment, at least) sites that are >> outside a firewall that your browser is behind the ability to make requests >> to hosts that are behind the firewall. >> >> Item 2 is somewhat of an issue for installed apps as well, of course, but >> installing an app is a trust decision. I would imagine browsers could relax >> some of these restrictions if a similar trust decision is explicitly made >> for a non-locally-hosted app. >> >> Item 1 is pretty specific to a web browser; the only way to avoid that issue >> is to run the app's XHRs in a special mode (effectively treating it as not >> running in the browser at all). >> >> -Boris >> > >
