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".

Contents

Access restriction

Overcoming access restriction

Vendor adoption

See also

External links

Access restriction

The philosophy of the same origin policy is simple: it is 'not' safe to trust content loaded from any websites. As semi-trusted scripts are run within the sandbox, they should only be allowed to access resources from the same website, but not resources from other websites, which could be malicious.
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 origin comparisons to the URL "http://www.example.com/dir/page.html".

URL	Outcome	Reason
http://www.example.com/dir2/other.html	Success
http://www.example.com/dir/inner/other.html	Success
https://www.example.com/dir2/other.html	Failure	Different protocol
http://en.example.com/dir2/other.html	Failure	Different host
http://example.com/dir2/other.html	Failure	Different host
http://www.example.com:81/dir2/other.html	Failure	Different port

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

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 recognised digital signature, especially not casual web developers. Also, 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 signed script is by no means a trustable script: it is trusted that the script comes from that origin, but it is still unknown what the script really does.
The same-origin policy does not apply to HTML files run from the local filesystem. This makes it possible for a locally-run HTML file to, for instance, perform any given HTTP request. The information here[1] and here[2] explain some of the potential problems, however applications such as TiddlyWiki[3] use this ability to save changes locally and simplify the XMLHttpRequest process.

Vendor adoption

This policy is used in modern web browsers that support client-side scripting. Internet Explorer uses an alternative approach of 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.

See also

★ Signed script policy

★ Cross-site scripting

★ Cross-site request forgery

External links

★ JavaScript Security: Same Origin (Mozilla)

★ JavaScript Security in Communicator 4.x (PDF)

★ Violating Same Origin Policy with XMLHttp: Cross-Browser Differences (SourceForge Wiki)

★ Second page of an article on JavaScript Security (focuses on Same Origin issues)

★ Same-Origin Policy Part 1: Why we’re stuck with things like XSS and XSRF/CSRF