Internet Explorer (IE) implements two major differences when it comes to the same-origin policy:

The following information box displays scenarios where DOM elements are allowed for cross-origin sharing:

The ability of WebSockets to bypass the same-origin policy is seen as a security risk. Using WebSockets on a gateway/server that supports origin-based security provides header-based security similar to CORS.

JavaScript APIs, such as iframe.contentWindow, window.parent, window.open, and window.opener, provide limited cross-origin access to the Window and Location objects. Some browsers permit access to more properties than the specification allows. You can use window.postMessage instead to communicate between documents in separate windows.

JavaScript data stored in the browser as Local Storage, or in IndexedDB, is separated by origin. Each origin has distinct storage, and JavaScript in one origin cannot read from or written to storage belonging to another origin unless it is given explicit access to a script on another domain by CORS or a similar method.

The CORS header whitelists access to one domain or any domain with the wildcard *. This header allows access from only one domain—the one specified:

Access-Control-Allow-Origin: http://localdomain.com

To enable access from multiple domains, a wild card is used:

Access-Control-Allow-Origin: *

The following example explains the CORS syntax, without actually doing anything with the responseText request:

IE 10 supports the working draft XMLHttpRequest level 2. Therefore, the withCredentials property can be used to detect CORS support in most browsers, including IE >= 10. To provide backwards compatibility for IE < 10, use its XDomainRequest property.

var request = createCORSRequest("get", "targetdomain.com/");
if (request){
    request.onload = function(){
        //do something with request.responseText
    };
    request.send();
}

This CORS request retrieves the page title from the target domain, targetdomain.com. It parses the responseText request to get the title and sends the target domain and the retrieved page title text to the console.log:

// Create the XHR object.
function createCORSRequest(method, url) {
  var xhr = new XMLHttpRequest();
  if ("withCredentials" in xhr) {
    // XHR for Chrome/Firefox/Opera/Safari and IE >= 10
    xhr.open(method, url, true);
  } else if (typeof XDomainRequest != "undefined") {
    // XDomainRequest for IE <= 9
    xhr = new XDomainRequest();
    xhr.open(method, url);
  } else {
    // CORS not supported
    xhr = null;
  }
  return xhr;
}

// utility function to parse the title tag from the response
function getTitle(text) {
  return text.match('<title>(.*)?</title>')[1];
}

// Make the actual CORS request
function makeCorsRequest() {
// we want the title of the page at targetdomain.com
  var url = 'targetdomain.com';
// use the GET method to return the entire page
  var xhr = createCORSRequest('GET', url);
  if (!xhr) {
    // log message if CORS is not supported
    console.log('CORS not supported');
    return;
  }
  // Response handlers.
  // on readyState = load
  xhr.onload = function() {
    // xhr.responseText contains the HTML for the page at targetdomain.com
    var text = xhr.responseText;
    // send the responseText to the utility function to extract the page title
    var title = getTitle(text);
    // do something with the processed responseText, in this case log a message
    console.log('response from request to ' + url + ': ' + title);
  };

  // error handler
  xhr.onerror = function() {
    console.log('error making the request');
  };

  // send the request
  xhr.send();
}

What happens in this CORS request?

You're probably thinking, "Big deal! I can get the title text in other ways.". But you could do more than retrieving a DOM element.

Let's consider a scenario in which you want to distribute a block-level DOM element, for example, a navigation menu from a target domain to multiple pages on multiple domains, along with customized CSS and JavaScript for the menu. You only change the navigation menu once on the target domain and copy it to multiple pages on multiple domains with CORS.

We will examine the pieces and then put them all together.

A script tag on the local domain embeds a script from the target domain. The same origin policy allows script tags to request resources across domains. The CORS script on the target domain will contain the createCORSRequest function and a request like this:

var request = createCORSRequest("GET", "targetdomain.com/header.php");

The CORS request allows you to GET a PHP file from the target domain and use it on the local domain.

You are not limited to requesting the HTML for a page on the target domain in the responseText request, as in example 2; header.php on the target domain may contain HTML, CSS, JavaScript, and any other code that is allowed in a PHP file.

If the request is successful, it returns the contents of header.php and replaces the contents of a DOM element #global-header on the local domain with the responseText request:

if (xhr){
  xhr.onload = function(){ 
    // do stuff if request is successful;
  document.getElementById('#global-header').innerHTML =       xhr.responseText ;
  };
 request.send();
}

Adding the Access-Control-Allow-Origin header in header.php on the target domain allows access from the local domain. Since header.php is a PHP file, we add the header with the PHP code. Use the wildcard * to allow access from any domain because we making the CORS request from multiple domains:

<?php
header('Access-Control-Allow-Origin: *');
?>

You can place the CORS request script on the target domain as cors_script.js and trigger it with the script tag on your local domain. The responseText request is sent to any local domain page that contains the script tag. The DOM selector #global-header is replaced on the local domain with the responseText request contents of header.php, which contains the navigation menu HTML, CSS, and JavaScript from the target domain. We are also going to replace the logo image on the local domain with the one from the target domain.

By placing a script tag on your local domain page, you can access a target domain from any local domain, run a script on it, and do something on your local domain:

<script src="http://targetdomain.com/cors_script.js"></script>

// Create the XHR object.
function createCORSRequest(method, url) {
  var xhr = new XMLHttpRequest();
  if ("withCredentials" in xhr) {
    // XHR for Chrome/Firefox/Opera/Safari and IE >= 10
    xhr.open(method, url, true);
  } else if (typeof XDomainRequest != "undefined") {
    // XDomainRequest for IE <= 9
    xhr = new XDomainRequest();
    xhr.open(method, url);
  } else {
    // CORS not supported
    xhr = null;
  }
  return xhr;
}

// set some variable values for use in the request processing
// the Target Domain  is contained in document.domain
var rawdomain = document.domain;
// add the http:// scheme
var sourceURL = "//" + rawdomain; // use the Protocol-relative shorthand //

// define XHR request
var request = createCORSRequest("get", sourceURL + "/[path-to-file]/header.php");

// send the request and process it if it is successful
if (request){
  request.onload = function(){ 
    // do stuff if CORS request is successful and loads
    // if it fails, there is no replacement of existing HTML in target site
    // replace contents of #global-header on Local Domain with the responseText
    document.getElementById('global-header').innerHTML = request.responseText;
    // use logo image from Target Domain inside #branding container
 on Local Domain
    document.getElementById('branding').getElementsByTagName('img')[0].src = sourceURL + '[path-to-logo]/targetdomain_logo.png';
  };
  request.send();
}

$http_origin = $_SERVER['HTTP_ORIGIN'];
if ($http_origin == "http://domain1.com" || $http_origin == "http://domain2.com" || $http_origin == "http://domain3.info")
{  
    header("Access-Control-Allow-Origin: $http_origin");
}

Most CORS request methods use either GET or POST, and less often HEAD. Keep these differences in mind when you are selecting the method to use:

To trigger a preflight, set custom headers on the XHR request; the Access-Control-Allow-Methods header determines which HTTP methods can be used.

if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
  // return only headers
  // The Preflight checks that the GET request method is supported
  if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD']) && $_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD'] == 'GET') {
    header('Access-Control-Allow-Origin: *');
    header('Access-Control-Allow-Headers: X-Requested-With');
  }
  exit;
}else{
  // error-handling code if the OPTIONS request method is unavailable
}

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With

CORS via jQuery does not use preflight.

jQuery specifically avoids setting the custom header when making a CORS request. Therefore, it is better to use a separate preflight method when using jQuery for CORS.

There are some common issues that developers face while implementing CORS preflight.

Any CORS request that uses a non-simple method or header requires preflight.

GET, POST, and HEAD are considered simple requests (and are case-sensitive). They do not require preflight.

The simple headers that do not require preflight are as follows:

Any other method or header requires preflight.

Using the XMLHttpRequest level 2 event HandlersOriginally, XMLHttpRequest had only one event handler: onreadystatechange. XMLHttpRequest2 introduces new event handlers.

You may have noticed that when defining the XHR objects, we have used request.onload, which corresponds to the onload event when the request has successfully completed since we are interested in knowing whether the request has been successful.

* IE's XdomainRequest does not support handlers marked with asterisks

Check whether withCredentials property is available to determine whether the browser supports XMLHttpRequest level 2 event handlers. This could be handled as a preflight.

A jQuery plugin for CORS is available at http://plugins.jquery.com/cors.

The plugin sends cross-domain AJAX requests through corsproxy.io.

Chapter 2, Creating Proxies for CORS, gives details about using proxies with CORS.

The standard would make JSON-P safer.

WebSocket provides full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF (https://tools.ietf.org/html/rfc6455) in 2011, and the WebSocket API is a candidate recommendation by the W3C (http://www.w3.org/TR/websockets/).

WebSocket uses TCP, not HTTP; nor does it use AJAX/XHR.

Socket.io provides a framework to use WebSocket by creating a node.js server for the socket (http://socket.io/).

The postMessage method is part of the W3c candidate recommendation for HTML5 Web Messaging ().

postMessage allows messages between discrete documents. The documents may include an iframe embedded in a document, or any other window objects.

The postMessage method dispatches MessageEvent in the target window when a script is completed.