Same origin policy

In computing, the same origin policy is an important security measure for client-side scripting (mostly JavaScript). The policy dates from Netscape Navigator 2.0, with necessary coverage fixes in Navigator 2.01 and Navigator 2.02. It prevents a document or script loaded from one "origin" from getting or setting properties of a document from a different "origin".

Access restriction

The philosophy of the same origin policy is simple: the browser should not trust content loaded from arbitrary websites. Web pages run within the sandbox are prevented from accessing resources from other origins. Without this protection, a malicious web page could compromise the confidentiality or integrity of another web page.

The term "origin" is defined using the domain name, protocol and port. Two pages belong to the same origin if and only if these three values are the same. To illustrate, the following table gives examples of potential outcomes and comparisons to the URL "http://www.example.com/dir/page.html".

By using relative URLs and limiting the use to URLs in the same origin, this restriction can be easily avoided.

For communication between a domain and its subdomain, the restriction can be overcome by setting the DOM property document.domain to the parent domain. Example: If a script from http://en.example.com sets document.domain="example.com", it can access content from http://example.com .

Overcoming access restriction

It is possible to "overcome" this restriction by signing the script. However, in practice signed script is rarely used. This is mainly because Internet Explorer does not support signed scripts, and not everyone can afford a widely recognized digital signature, especially not casual web developers. Even if the script is signed, a prompt window would appear whenever the script required access to extended privileges. This is another security measure (as a signed script is not necessarily a script that can be trusted): it is trusted that the script comes from that origin, but it is still unknown what the script actually does.

The same-origin policy is overcome when users save the untrusted HTML files and run them from the local filesystem. This makes it possible for a locally-run HTML file to, for instance, retrieve data from the local filesystem. The information [http://www.gnucitizen.org/blog/web-pages-from-hell here] and [http://www.gnucitizen.org/blog/web-pages-from-hell-2 here] explain some of the potential problems, however applications such as [http://www.tiddlywiki.com TiddlyWiki] use this ability to save changes locally and simplify the XMLHttpRequest process.

It is also possible to implement a proxy script on the server.

JSON

While it is not possible to directly query websites for data due to the same origin policy, the <script> tag does not honor the same-origin policy and can be used in conjunction with JSON.

DNS rebinding

The DNS basis of the same origin policy can be subverted by setting a very low TTL at an attacker's DNS server and returning forged responses to subsequent DNS requests.

Session hijack

:"Main article: Cross-site request forgery

The same-origin policy doesn't restrict posting data (via POST or GET method). The javascript can still send HTTP POST/GET request to any domain, but it just can't access the contents of the data returned from that request (because of same-origin policy). The stored cookies will be sent along with that HTTP request. It can then hijack the cookies session, and do any transaction blindly.

Some web applications, prevent this session hijack by adding another credential token into the request form. This token is embeded in HTML, and can't be read by the script on the other domain due to same-origin policy. The field "wpEditToken" in the edit form of MediaWiki software is an example of this.

Vendor adoption

This policy is used in modern web browsers that support client-side scripting. Internet Explorer uses an alternative approach of [http://www.microsoft.com/windows/ie/using/howto/security/settings.mspx security zones] in addition to the same-origin (or "same-site") policy. By default in Internet Explorer, internet web sites are restricted to their site-of-origin, but the user may choose to allow local intranet sites (or sites that they have explicitly trusted) to access data across domains (up to Internet Explorer 5). This is useful for certain types of applications that need to aggregate data from multiple sites, such as trusted internal portals.

ee also

*Cross-site scripting
*Cross-site request forgery

External links

* [http://www.mozilla.org/projects/security/components/same-origin.html JavaScript Security: Same Origin (Mozilla)]
* [http://www.jsdir.com/red/jssecurity.pdf JavaScript Security in Communicator 4.x (PDF)]
* [http://web.archive.org/web/20050404123540/http://jpspan.sourceforge.net/wiki/doku.php?id=javascript:xmlhttprequest:behaviour#security Violating Same Origin Policy with XMLHttp: Cross-Browser Differences (SourceForge Wiki)]
* [http://www.devarticles.com/c/a/JavaScript/JavaScript-Security/1/ Second page of an article on JavaScript Security (focuses on Same Origin issues)]
* [http://taossa.com/index.php/2007/02/08/same-origin-policy/ Same-Origin Policy Part 1: Why we’re stuck with things like XSS and XSRF/CSRF]