Why IE XDomainRequest does not send Referer header

Question

When I am doing CORS in IE via XDomainRequest object, the Referer HTTP header is not being sent. Is there any official documentatation covering this? I fully understand, that relying on Referer HTTP header is basicaly wrong idea, however without hard evidence I am stuck here, and not able to prove our architect wrong.

Example dump:

IE Request

GET http://example.com/some/url HTTP/1.1
Accept: */*
Origin: http://another.domain.com
Accept-Language: sk-SK
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3)
Host: example.com
Connection: Keep-Alive
Pragma: no-cache

Chrome Request

GET http://example.com/some/url HTTP/1.1
Host: example.com
Connection: keep-alive
Origin: http://another.domain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36
Accept: */*
Referer: http://another.domain.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: sk-SK,sk;q=0.8,cs;q=0.6,en-US;q=0.4,en;q=0.2

Answer 1

Eric Law (former IE program manager) answered this in his blog post, as expected limitation comming back from IE8 times:

we wanted to ensure that the XDomainRequest object would not allow an attacker to issue a request that a HTML Form could not issue. This is important because the Access-Control-Allow-Origin header isn’t available until after the response is returned, so there’s no way to tell before the request is issued whether or not the server is willing to accept cross-domain HTTP requests. Without these restrictions, a “Fire and Forget” CSRF attack could take place against a legacy server, even if the server doesn’t return the Access-Control-Allow-Origin header

http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

Answer 2

Cross-domain requests ("XDRs") are anonymous to protect user data. This means that servers cannot easily determine who is requesting data. To protect user privacy, respond with cross-domain data that is neither sensitive nor personally identifiable. To help prevent intranet data from being leaked to malicious Internet sites, we discourage intranet sites from making XDR data available. So the IE some times prevent XDomainRequest object due to security resons.

Answer 3

According to Microsoft's own page, you can use this new object to avoid this problem:

/ / 1. Create XDR object
XDomainRequest xdr = new ();

/ / 2. Open the connection to the server using the POST method
xdr.open ("POST", "http://www.example.com/xdr.txt");

/ / 3. We send information to the server
xdr.send ("data to be processed");

According to W3C, you can use this

var xhr = new XMLHttpRequest();
xhr.open("GET", "http://www.example.com/.../datos.php", true);
xhr.onreadystatechange = function(){
  if ( xhr.readyState == 4 ) {
    if ( xhr.status == 200 ) {
      document.body.innerHTML = "Reply: " + xhr.responseText;
    } else {
      document.body.innerHTML = "ERROR";
    }
  }
};
xhr.send(null);

There is also a library for IE8 and IE9, to avoid this problem, but you should use jquery Ajax https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest