In computing, the same-origin policy is an important concept in the web application security
model.
The policy permits scripts running on pages originating from the same site – a combination
of scheme, hostname, and port number – to access each other's DOM with no specific restrictions,
but prevents access to DOM on different sites.
The same-origin policy also applies to XMLHttpRequest and to WebSocket.
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.
History The concept of same-origin policy dates back
to Netscape Navigator 2 in 1995.
All modern browsers implement some form of the Cross Origin Policy as it is an important
security cornerstone.
The policies are not required to match an exact specification but 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 algorithm used to calculate the "origin"
of a URI is specified in RFC 6454, Section 4.
For absolute URIs, the origin is the triple {protocol, host, port}.
If the URI does not use a hierarchical element as a naming authority or if the URI is not
an absolute URI, then a globally unique identifier is used.
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.compage.html".
Unlike other browsers, Internet Explorer does not include the port in the calculation of
the origin, using the Security Zone in its place.
Relaxing the same-origin policy In some circumstances the same-origin policy
is too restrictive, posing problems for large websites that use multiple subdomains.
Here are four techniques for relaxing it: document.domain property
If two windows 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 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.
JSONP JSONP allows a page to receive JSON data from
a different domain by adding a element to the page which loads a JSON response from
a different domain.
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 pseudo-protocols
that do not have a clearly defined host name or port associated with their URLs.
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.
In addition, many legacy cross-domain operations predating JavaScript are not subjected to
same-origin checks; one such example is the ability to include scripts across domains,
or submit POST forms.
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.
Workarounds 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
Cross-site scripting Cross-site request forgery
Cross-document messaging References
External links A detailed comparison of several flavors of
same-origin policies A review of deficiencies in same-origin policies
and their implication for web security at the Wayback Machine
Sample vendor-provided same-origin policy specification
The HTML5 spec's definition of Origin WC3 Article on the Same Origin Policy
RFC 6454 on The Web Origin Concept