Same origin policy
||This article needs additional citations for verification. (November 2011)|
This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity.
The concept of same origin policy dates back to Netscape Navigator 2.0. Close derivatives of the original design are used in all current browsers and are often extended to define roughly compatible security boundaries for other web scripting languages, such as Adobe Flash or Adobe Acrobat, or for mechanisms other than direct DOM manipulation, such as XMLHttpRequest.
Origin determination rules 
The term "origin" is defined using the domain name, application layer protocol, and (in most browsers) port number of the HTML document running the script. Two resources are considered to be of the same origin if and only if all these values are exactly the same.
To illustrate, the following table gives an overview of typical outcomes for checks against the URL "http://www.example.com/dir/page.html".
|httpː//www.example.com/dir/page2.html||Success||Same protocol and host|
|httpː//www.example.com/dir2/other.html||Success||Same protocol and host|
|httpː//www.example.com:81/dir/other.html||Failure||Same protocol and host but different port|
|http://example.com/dir/other.html||Failure||Different host (exact match required)|
|http://v2.www.example.com/dir/other.html||Failure||Different host (exact match required)|
|httpː//www.example.com:80/dir/other.html||Don't use||Port explicit. Depends on implementation in browser.|
Relaxing the same-origin policy 
In some circumstances the same-origin policy is too restrictive, posing problems for large websites that use multiple subdomains. There are three techniques for relaxing it:
document.domain property 
If two windows (or frames) contain scripts that set domain to the same value, the same-origin policy is relaxed for these two windows, and each window can interact with the other. For example, cooperating scripts in documents loaded from orders.example.com and catalog.example.com might set their document.domain properties to “example.com”, thereby making the documents appear to have the same origin and enabling each document to read properties of the other. This might not always work as the port stored in the internal representation can become marked as null. In other words example.com port 80 will become example.com port null because we update document.domain . Port null might not be treated as 80 ( depending on your browser ) and hence might fail or succeed depending on your browser.
Cross-Origin Resource Sharing 
The second technique for relaxing the same-origin policy is being standardized under the name Cross-Origin Resource Sharing. This draft standard extends HTTP with a new Origin request header and a new Access-Control-Allow-Origin response header. It allows servers to use a header to explicitly list origins that may request a file or to use a wildcard and allow a file to be requested by any site. Browsers such as Firefox 3.5 and Safari 4 use this new header to allow the cross-origin HTTP requests with XMLHttpRequest that would otherwise have been forbidden by the same-origin policy.
Cross-document messaging 
Another new technique, cross-document messaging allows a script from one page to pass textual messages to a script on another page regardless of the script origins. Calling the postMessage() method on a Window object asynchronously fires an "onmessage" event in that window, triggering any user-defined event handlers. A script in one page still cannot directly access methods or variables in the other page, but they can communicate safely through this message-passing technique.
Corner cases and exceptions 
The behavior of same-origin checks and related mechanisms is not well-defined in a number of corner cases, such as for protocols that do not have a clearly defined host name or port associated with their URLs (file:, data:, etc.). This historically caused a fair number of security problems, such as the generally undesirable ability of any locally stored HTML file to access all other files on the disk, or communicate with any site on the Internet.
Lastly, certain types of attacks, such as DNS rebinding or server-side proxies, permit the host name check to be partly subverted, and make it possible for rogue web pages to directly interact with sites through addresses other than their "true", canonical origin. The impact of such attacks is limited to very specific scenarios, since the browser still believes that it is interacting with the attacker's site, and therefore does not disclose third-party cookies or other sensitive information to the attacker.
To enable developers to, in a controlled manner, circumvent the same origin policy, a number of "hacks" such as using the fragment identifier or the
window.name property have been used to pass data between documents residing in different domains. With the HTML5 standard, a method was formalized for this: the
postMessage interface, which is only available on recent browsers. JSONP can also be used to enable ajax-like calls to other domains.
See also 
- Cross-origin resource sharing (CORS)
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF)
- Cross-document messaging
- Robots.txt Specifications on Google Webmasters Retrieved on December 6, 2012.
- HTML Living Standard. Communication: Cross-document messaging: Posting messages — WHATWG.
- HTML5. Communication: Cross-document messaging: Posting messages — W3C.
- When can I use: Support for Cross-document messaging
- "Blog Post: Using CORS with all (modern) browsers".