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/1.1
Accept: */*
Origin: 
Accept-Language: sk-SK
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (patible; 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
Connection: Keep-Alive
Pragma: no-cache

Chrome Request

GET  HTTP/1.1
Host: example
Connection: keep-alive
Origin: 
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: /
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

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./some/url HTTP/1.1
Accept: */*
Origin: http://another.domain.
Accept-Language: sk-SK
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (patible; 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.
Connection: Keep-Alive
Pragma: no-cache

Chrome Request

GET http://example./some/url HTTP/1.1
Host: example.
Connection: keep-alive
Origin: http://another.domain.
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./
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

• javascript
• internet-explorer
• http-referer
• xdomainrequest

Share Improve this question Follow edited Dec 28, 2019 at 7:49 sideshowbarker♦ 88.6k3030 gold badges215215 silver badges212212 bronze badges asked Oct 14, 2013 at 7:00 Marian BazalikMarian Bazalik 1,40511 gold badge1414 silver badges3131 bronze badges 2

• 1 IE8 could be considering the Referrer header as user-identifying information: msdn.microsoft./en-us/library/ie/cc288060(v=vs.85).aspx – Qantas 94 Heavy Commented Oct 19, 2013 at 8:26
• That would make sense, however I was not able this being documented anywhere – Marian Bazalik Commented Oct 20, 2013 at 6:33

Add a ment  | 

3 Answers 3

Sorted by: Reset to default 2

Eric Law (former IE program manager) answered this in his blog post, as expected limitation ming 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./b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

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.

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./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./.../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./MoonScript/jQuery-ajaxTransport-XDomainRequest