Same Origin Policy and ways to Bypass

This is something that really got my attention when I started with Web Security.

Learning Same Origin Policy…

I am the type of Software Engineer that when I find something fascinating, I want to learn how it really works and I hope you do too.

Let’s start by saying a little bit about Same Origin Policy and why we need it.

Same Origin Policy (or SOP), to keep this simple, prevents JavaScript code from one origin like “website1.example” to access private data on another origin “website2.example”.

Same Origin Policy == JavaScript code can access/read data that come ONLY from the Same Origin.

In other words Cross-Origin reads are not allowed.

Here I have to make clear that Same Origin Policy doesn’t block a Request from one origin to reach its destination, all it does is to hide the Response.

For example JavaScript from “website1.example” cannot access my profile data in “website2.example/myprofile” because again Same Origin Policy doesn’t allow Cross Origin reads.

Another example would be that JavaScript coming from “website1.example” cannot access the JavaScript code and also the DOM of “mywebbanking.example” page.

By now you probably get it, we can’t live without SOP.

But wait, what if I need the JavaScript code in my website to access some data like pictures, personal information of my users from another API or even some other JavaScript code from another origin? Can I do that ?

Or what if I want my Restful API to be consumed by applications running on different origins ?

So, sometimes you need to bypass SOP because you need a certain functionality to your application.

So, here are 2 simple ways to bypass Same Origin Policy :

1) JSONP

JSONP enables sharing of data bypassing SOP.

When I first saw this “hack” my brain almost explode, by the elegance and beauty of the way it works.

Can’t wait to explain this to you :P

Of course you all know the <script> element that allows us to add JavaScript code to an HTML.

This famous <script> element is allowed to execute JavaScript code that is retrieved from foreign origins. Pretty obvious, right?

Everyone has already done it with including some JavaScript library like with Bootstrap for example.

That means that SOP doesn’t block <script> element from retrieving content of another origin.

Great!, so What about JSONP? What is JSONP?

JSONP ==JSON with Padding

So <script src=”website1.example/static/JavaScriptLib.js”> retrieves JavaScript code by performing a GET Request to the value of src.

But what if I want to retrieve some JSON objects and get some data.

That would be really helpful.

In order to accomplish this you need to have a JavaScript function like

mycallback = function(data){
  console.log(data)
};

Now let’s say that I have this URI : https://www.myexampleuri.net/data

that when you perform a GET Request to it, you will get some JSON data like:

{name: "John", numberOfPosts:12, numberOfLikes:61}

Now imagine that this endpoint in our server is JSONP enabled which means that when I perform a GET Request to :

https://www.myexampleuri.net/data?callback=mycallback

I receive back something like :

mycallback({name: “John”, numberOfPosts:12, numberOfLikes:61});

Now lets say that in my front end code I have something like

<script src=https://www.myexampleuri.net/data?callback=mycallback></script>

The above element will perform a GET Request to our server and it will look something like this :

<script>
     mycallback({name: “John”, numberOfPosts:12, numberOfLikes:61});
</script>

This will trigger the function “mycallback” with the above parameters.

BOOM we retrieved some JSON data and we are ready to process it!!!

2) CORS

CORS or Cross Origin Resource Sharing is a mechanism to tell the browser to allow some data to be accessed from a different origin.

If you are developing single page applications you have already come across CORS mechanism.

The way CORS work is for example when JavaScript from origin “website1.example” Requests data from another origin “website2.example” the browser blocks the Response so that it doesn’t reach the JavaScript code in “website1.example”.

Now, what if the application server in “website2.example” wants to ask the browser to allow the Response to reach the JavaScript code of “website1.example” ?

This can be easily solved by adding the following Header in our server-side Response:

Access-Control-Allow-Origin: https://website1.example

This way most single page applications and Restful APIs work.

Nowadays a huge number of Restful Services are available for developers to use.

Let’s say for example that you have created a small app in Angular6 and you want to add some Google analytics functionality because you want to monitor how your users interact with your application.

Now Google, in order to allow your application to consume the Google analytics API, has added this extra Header to every Response.

Also if you are in the process of creating a Restful API you are going to have to enable some kind of CORS in order for it to be consumable by applications running on different origins.

Here you have to be careful about which applications you allow to have access to your content and also what kind of access.

I am saying this because many developers without understanding how CORS work, are just allowing every foreign application under the sun to consume their API by adding the following Header: Access-Control-Allow-Origin: *

A good practice would be to specify the Request methods that you want to allow cross origin like POST or DELETE, with a Header like :

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

Sometimes you don’t want to allow an application with different origin to execute POST Requests and retrieve the Response of such Requests.

Last but not least, for more security, try to keep a whitelist of every origin/application that you want to allow to consume your API along with the appropriate methods.

Thanks for reading!