Tag Archives: same origin policy

A brief overview of same-origin policy

Can My JavaScript Access Your Page Elements?

We all know that using JavaScript you can do many things for example read elements on a page, analyze the DOM etc. Now assume that you logged into and in another browser tab visited The question is can a script present in access the elements on the page loaded by The answer is a big NO. Imagine the chaos it would have caused if the answer is yes! But the scripts loaded by can happily access the page elements. So how does the browser decide which script can access which page? This is where Same Origin Policy comes in! SOP is one of the most important security concepts that govern how the modern web browsers work. This article explores about SOP, SOP rules and some techniques to bypass SOP.

Same-Origin Policy

Same-Origin Policy permits scripts running on pages originating from the ‘same site’ or ‘same origin’ to access each other’s DOM with no specific restrictions, but prevents access to DOM on different sites. So the how does browser identify whether the script and the page are from ‘same origin’ or not? The origin is calculated based on the combination of scheme, host and port. For example the scheme, host and port for are calculated as below:


Browsers consider two resources to be of the same origin if and only if all these values are exactly the same. For example and are not same origin because the host is different.

Note: IE browser has 2 exceptions while checking for same origin

  1. IE doesn’t include port while calculating ‘origin’
  2. Same origin policy is not applied for sites which are under highly trusted zone.

Also note that SOP is not just limited to JavaScript. It also applies for XMLHttpRequest, Cookies, and Flash etc. We will see more about the same in the below sections.

Exceptions to SOP and their risks

SOP poses significant problems to large website which use multiple domains (due to the difference in the hostname).  Hence there are some exceptions which can be used to relax it.

Scripts that set domain to the same value:

You can use JavaScript to set the value of document.domain property. If two pages contain scripts which set domain to the same value, the SOP is relaxed for these two windows, and each window can interact with the other. For example, consider the earlier scenario where a script present on cannot access the DOM of a page loaded by Now if this script (present on sets its document.domain to then the script can happily access the DOM. Also note that a script cannot set the value of document.domain to any hostname. It can set the value only to a suffix of the current domain.

Risk: This is relatively safe because we are only talking about sub domains of a site. So scope for someone exploiting this is relatively low unless the sub domain is compromised.

CORS [Cross Origin Resource Sharing]:

CORS is a HTML5 feature that allows one site to access another site’s resources even if both are of different domains. Hence with CORS, JavaScript on a webpage can initiate an AJAX request to another site. To allow this process, the server which implements CORS, adds a HTTP header named ‘Access-Control-Allow-Origin:’ in the response. Now the even though is not of same origin can access this server’s pages.

Risk: Developers often tend to use ‘*’ to get the things working. CORS, being relatively new concept, is often misunderstood. If a site sets Access-Control-Allow-Origin:* it means an attacker can initiate AJAX request to this site with his JavaScript and can access the resources.  Hence while security testing a HTML5 site which has CORS enabled, look for Access-Control-Allow-Origin header to check if it allows only the allowed sites.

CDM [Cross Document Messaging]:

CDM or Cross Document Messaging is also one of the features introduced in HTML 5. This feature allows documents to communicate with one another across different domains. For example, Document A present on can communicate with document X present on (assume its present as an iframe) by issuing the below request from JavaScript:

var c = document.getElementsByTagName(‘iframe’)[0];
c.contentWindow.postMessage(‘Hiee’, ‘’);

Upon receiving this request, the script present on can respond back using the event listener.

function receiver(event) {
     if (event.origin == '') {
         if ( == 'Hiee') {
            event.source.postMessage('how are you?', event.origin);
         else {
               } } }



Repeating the golden rule – You cannot make a cross domain Ajax request to update a current page. Here it is important to note that SOP does not restrict a site from loading JavaScript files from a different domain. With JSOP, by adding a <script> element to the page you can load JSON response from different domain. Because the code is loaded by the <script> tag, it can be normally executed. The below figure sums up everything!


Risk: Suppose a page hosted on uses JSONP to access services provided by then, the site has to completely trust From security perspective, excessive trust on other sites is never good. If is malicious it can run malicious code on the page loaded by Also a malicious page can request and obtain JSON data of another site by using the <script> tag and hence can be used to launch CSRF attacks.

Getting Around SOP


Internet Explorer:
-> Go to the Security tab. For the current zone click the ‘Custom level’ button.

IE security settings

-> Open the Mozilla browser and enter ‘about:config’
-> Search for security.fileuri.strict_origin_policy and change the value to false by double clicking it as shown below.

firefox security settings

Google Chrome:
-> Start the chrome by passing the below argument:

-> Start the Safari by passing the below argument:



Posted by on April 30, 2014 in web application hacking


Tags: , ,