If you work with Web Development or Javascript / Ajax a lot you must have come across browser’s same origin policy or SOP. Same Origin Policy or SOP is a security concept in which documents retrieved from distinct origins are isolated from each other. This is quite strictly implemented by almost all major browsers today.

An origin is defined by a host name, protocol and the port. For example a document located on http://example.com/page.html is not allowed to access the DOM of the document located on https://example.com/test.html because they are on two different protocols (http vs https).

Same restriction applies if the host name (example.com) and the port (80) are also different from each other. The same-origin policy differs between APIs, the intent is to let users visit untrusted web sites without those web sites interfering with the user’s session with honest web sites.

Why do we need SOP?

Modern web applications that extensively depend on cookies to maintain sensitive information i.e. authenticated user sessions, as servers act based on the cookie information to reveal sensitive information or take 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. Wihtout an SOP policy strictly in place users will be exposed to Cross Site Request Forgery (CSRF) or Cross Site Scripting (XSS)

Effect on XMLHttpRequest

Standardizing of XMLHttpRequest object across major browsers was a big deal. This really kick started the wide adaption of Ajax and a zillion Ajax Applications and libraries sprung up.

XMLHttpRequest specification defines an API that provides scripted client functionality for transferring data between a client and a server.

SOP particularly is a problem for Ajax based applications. A lot of people like to separate their content like we do. In particular we like to separate our static content (images/ javascript files) from our dynamic content. Specially when our dynamic content is of different types and comes from different places.

Imagine a web page or portal which has different sections on the page i.e. news feed, head lines, weather information, stock information etc. It will be quite rare for all that information to come from same origin, unless you have a huge monolithic backend.

With browsers strictly implementing SOP , JavaScript programmers have had a big problem. If you have a very big javascript program which have multiple javascript file and html files you will be hit in two places

1. You will be prevented from loading of all the java script pieces from a different domain
2. Javascript making dynamic calls to remote servlets or backends across different domains will be blocked by the browsers or subject to CORS protocol.

How to get around SOP

Good news is, there are plenty of ways around it. W3C has also published an RFC addressing SOP issues which is getting more and more standard support in browsers. We have basically the following options

1. Proxy and Reverse Proxy

The first option is to play by the rules of SOP and create a proxy on your local server. You can then make HTTP calls to your local server and have it go fetch the data from the remote server. This works because the code running on your web server is not subject to SOP restrictions. Only the client-side code is.

2. Dynamically Inject the ‘src’ of a <script> tag

Another option is to dynamically load JavaScript into a <script> tag. Client-side JavaScript can manipulate <script> tags, just like any other element in the HTML Document Object Model (DOM).

Client-side code can set the src attribute of a <script> tag to automatically download and execute new JavaScript into the page. This strategy is not subject to SOP restrictions. So you can effectively use it to load JavaScript. One way to do this is to completely inject a <script> tag into your DOM like below

 var head= document.getElementsByTagName('head')[0];
 var script= document.createElement('script');
 script.type= 'text/javascript';
 script.src= 'helper.js';
 head.appendChild(script);

Other approach could be to dynamically set just the ‘src’ attribute like below

   <script id='loadarea' type='text/javascript'/>

   document.getElementById('loadarea').src= 'helper.js';

Dynamically loading the JavaScript into a script tag solves the SOP issue but introduces another.

When you use this method to load JavaScript, although the browser retrieves the code asynchronously, it doesn’t notify you when it’s finished. Instead, it simply executes the new JavaScript. However, by definition, JSON cannot contain executable code. Put the two together and you’ll realize that you can’t load plain JSON data using a ; tag.

3. JSONP (JSON with Padding)

If you use JSON in your application, you can make use of JSONP (JSON with padding). In this technique you set the src of a script tag to be a remote JSON call, which returns the JSON data which is prefixed with a function name in the current browser’s context. This in turn makes the browser execute that function and hence allows you to exchange JSON data across origins. Consider the following

 <script type="text/javascript"
    src="http://static.example.com/GetUser?UserId=1234>
 </script>

process({"Name": "Usama", "Id" : 1234)

4. Cross-Origin Resource Sharing (CORS)

Here is a brief introduction of how this works. Lets say your page is located on http://www.example.com/page.html and doing requests to static.example.com

Origin : http://example.com

 Access-Control-Request-Method: PUT

 Access-Control-Allow-Methods: PUT, DELETE, POST

 Access-Control-Request-Headers: Content-type

 Access-Control-Allow-Headers: Content-type, X-3GPP-Identity

Header set Access-Control-Allow-Origin *
Header set Access-Control-Allow-Headers x-gwt-module-base
Header add Access-Control-Allow-Headers content-type
Header add Access-Control-Allow-Headers x-gwt-permutation

Access-Control-Max-Age : 1800

 add-linker name="xs"