Cross-Origin Resource Sharing (CORS)

Spec Details :
When building complex client-side applications, at some point it usually becomes necessary to make Ajax requests to domains other than the one from which your page originated.  This is especially true if you are part of a large enterprise with distributed sub-domain resources. Over the years, various techniques have been employed to work around this security restriction, such as server-side proxies, JSONP, and iframe proxies using post message.
With the emergence of the Cross Origin Resource Sharing (CORS) specification, now a candidate for W3C Recommendation, web application developers have a browser-supported mechanism to make XmlHttpRequests to another domain in a secure manner.
The use-case for CORS is simple. Imagine the site has some data that the site wants to access. This type of request traditionally wouldn’t be allowed under the browser’s same origin policy. However, by supporting CORS requests, can add a few special response headers that allow to access the data.
As you can see from this example, CORS support requires coordination between both the server and client. Luckily, if you are a client-side developer you are shielded from most of these details. The rest of this article shows how clients can make cross-origin requests, and how servers can configure themselves to support CORS.
CORS is supported in the following browsers:
·         Chrome 3+
·         Firefox 3.5+
·         Opera 12+
·         Safari 4+
·         Internet Explorer 8+
(See the complete list of supported browsers at
Chrome, Firefox, Opera and Safari all use the XMLHttpRequest2 object. Internet Explorer uses the similar XDomainRequest object, which works in much the same way as its XMLHttpRequest counterpart, but adds additional security precautions.
How does it Work?
The CORS mechanism works by adding HTTP headers to cross-domain HTTP requests and responses.  When the client (browser) makes cross-origin requests, it includes the HTTP header - Origin - which announces the requesting domain to the target server. If the server wants to allow the cross-origin request, it has to echo back the Origin in the HTTP response header - Access-Control-Allow-Origin.This exchange of headers is what makes CORS a secure mechanism.  
NOTE: The server can also echo back "*" as the Access-Control-Allow-Origin value if it wants to be more open-ended with its security policy.
Alternatives to CORS
If your web application must run in browsers that do not support CORS or interact with servers that are not CORS-enabled, there are several alternatives to CORS that have been utilized to solve the cross-origin communication restriction.
§  JSONP. This is a technique that exploits the HTML script element exception to the same-origin security policy.  Script tags can load JavaScript from a different domain and query parameters can be added to the script URI to pass information to the server hosting the script about the resources that you wish to access. The JSONP server will return JavaScript that is evaluated in the browser that calls an agreed upon JavaScript function already on the page to pass server resource data into your page.
§  OpenAjax Hub. This is an JavaScript Ajax library that allows integration of multiple client-side components within a single web application. Trusted and untrusted components to co-exist within the same page and communicate with each other as long as they all include the OpenAjax Hub JavaScript library. The framework provides a security manager to allow the application to set security policies on component messaging. Iframes are used to isolate components into secure sandboxes.
§  easyXDM. This is a JavaScript library that allows for string-based cross domain communication via iframes.  It works on the same principals as OpenAjax Hub but does not have the security manager component.
§  Proxies Iframe. This do-it-yourself technique involves including an iframe on your page from the domain you wish to communicate with.  This assumes that you are able to host pages on this other domain.  The JavaScript running in the iframe serves as a rest proxy to the server containing the resources you wish to access.  Communication between your application and the rest proxy will take place using post message.  Post message is part of the HTML5 standard, but there is also a jQuery implementation for non HTML5-compliant browsers.
Reference Link :