The JavaScript Same-Origin Policy

One fundamental security feature for web browsers is the same-origin policy. Introduced in Netscape Navigator 2.0, this policy provides restrictions on how web content interacts with JavaScript and other browser-based programming languages. Although there are several scenarios in which this policy will affect JavaScript code, the policy typically comes into effect when a page includes iframe elements or opens a link in a new window. For more information on JavaScript, see my article "JavaScript: Is It as Good as They Say?" for essential books, tutorials, and resources for web development.

The policy restricts the interactions of code in one window or frame with the content of other windows or frames. The important concept is that a script can interact with content and properties that have the same origin as the page that contains the script. The policy doesn't restrict code based on the origin of the script, but only for the origin of content.

The purpose of the same-origin policy is to prevent scripts from accessing malicious content. Without the same-origin policy, a script could open a new browser window and trick the user into accessing sensitive content. The script could then read the content and transmit it to another server. The same-origin policy prevents this type of malicious behavior.

Understanding the Same-Origin Policy

Here's an example of how the same-origin policy applies to content from different origins. Let's say that a script hosted on myhost.com is embedded in a web page that's hosted on yourhost.com using the script element's src attribute. The origin of the script is yourhost.com. This might be confusing, but the origin of the script is the page's domain in which it's embedded. The script has full access to the content and properties of any page that's hosted on yourhost.com regardless of whether it's opened in new window or iframe. But if the script opens a new window and loads a document from myhost.com or any other domain, then the same origin policy comes into effect in which the script can't access the document's content or properties.

The origin of a document includes the combination of the protocol, host, and URL port that's used to access content on the web. All three of these factors must be identical in the URLs that are used to access the content in order to have the same origin. Table 1, which I derived from Wikipedia's same-origin policy entry, summarizes how this policy works. For example, let's say that the browser has opened the page at http://www.example.com/page.html. Table 1 indicates whether the content that's loaded into a new window has the same origin as the original page for several different URLs. As you can see, the rules are rather exacting.

Table 1: How the same-origin policy works for a browser that opens a new page.

The same-origin policy applies to virtually all objects' properties in a window that's from a different origin; including most of the properties in the Document object. Although a script can open a window, load content from a different origin, and then close the window, it can't access the content for practical purposes.

3 Ways to Circumvent the Same-Origin Policy

Although the policy is designed and intended to protect sensitive content, there are legitimate reasons to relax its restrictions in controlled ways. For example, you might want to allow a script to access content across all subdomains, such as www.api.example.com and www.home.example.com. Three interesting solutions come to my mind to relax the policy's restrictions.

The first solution provides support for using a script across subdomains. For this you can use the domain property of the Document object, which by default contains the server's host name from the page that's loaded by the browser. If the domain property is the same for two windows, then a script in one window can access the content of the other window. If you set the property to example.com for two windows, then a script embedded in one window can access the content in the other window that's loaded from any subdomain of example.com. The value for domain must have at least one dot in it, so you can't set it to "com" or any other top-level domain.

An emerging option for relaxing the same-origin policy is a new W3C standard called cross-origin resource sharing. Currently the standard is a Working Draft, which means that the standard is a work in progress. If the standard is adopted and implemented by several web browsers, then it would extend HTTP with a new origin qualification: request header and a new Access-Control-Allow-Origin response header. With these headers, a server could list URL origins that might request content that's accessible by a script.

HTML5's Web Messaging feature lets a script in one document pass messages to a script in another document, no matter the origin of the two documents. The feature uses a postMessage method on the Window object to asynchronously deliver a text message that raises a message event in the other window, which can be handled with an onmessage event handler. This technique doesn't let a script in one document directly access the content in another window with a different origin, but instead provides a controlled way to communicate information between windows.

The same-origin policy provides some significant protection against malicious scripts, but it can be a hindrance to building complex websites that let the user interact with content from several places on the web. Web developers need to know how to work with its restrictions to circumvent the policy in controlled ways to provide users with rich websites that are full of interesting content.