Using Proxy to bypass same origin policy for cross domain site in web dev prototyping

Same origin policy is a clever feature that prevents attackers from getting your user information by injecting cross site script into your website. This policy is just great for production website, but it is often a pain for prototyper that has to deal with this policy during development. This article discussed some of the common methods to deal with same origin policy during development and how to make the life of a prototyper, like you and me, easier.

Browser Settings
One way to deal with it is to change browser settings. Note that changing the browser's setting is different for each browser vendor. For example, to turn off same origin policy in Firefox, open the about config as below and change it to false.

about:config -> security.fileuri.strict_origin_policy -> false

 It is a bit different in Chromium as the browser need to be started with command line.

chromium-browser --disable-web-security

So, same origin policy can be switched off in these browsers. But for me, I won't do that because I will forget to switch it ON later on. The good thing is, changing the browser setting is not the only method to bypass same origin policy.

Reverse Proxy

Look up "reverse proxy" in wiki or google it. Reverse proxy is not only an elegant way to deal with same origin policy, it is also can be used in production environment. Well, most of the popular web servers such as NginX, Apache Web Server or IIS support reverse proxy (for IIS it is rewrite). There are tons of tutorial to configure it. The problem with reverse proxy is that it requires web server configuration. If you have a system administrator to help you with it, great! Most often, good prototyper will not want to trouble others (I am referring to myself).

Proxy Script

Personally, I love to use proxy script. Proxy script is a simple script that works like a router. It routes all your webpage API call to the endpoint and return the result as if you are calling the API endpoint directly. Here is a bit of details on how to use it. First, you install a proxy script to your development web server. Then, for every API call from your webpage, use the proxy script in your url. Since the proxy script can have the same origin as your webpage, because both are hosted on the same web server, the browser treat it like you are calling from the same origin. Therefore, the browser will not block the call. The catch is, you will need to remove the script and remove it from your code after you use it. 

Here are some of the PHP proxy script I wrote and used for my prototyping needs:

- https://github.com/anthonyzee/proxysoap

HTTP header or Cross Origin Resource Sharing (CORS)

You might asked, can my web services be configured to bypass same origin policy without the user/browser doing anything? Your answer is

Access-Control-Allow-Origin

You can set it in your web services' response HTTP header to allow certain/all origin accessed to your web services. Planning your website CORS takes effort and a lot of consideration to prevent any cross site script attack from happening. This is just too much work for a prototyper like me.

In conclusion, same origin policy do annoy prototyper like me a bit, but it is a great security feature. There are plenty of ways to bypass the same origin policy or to configure how same origin policy works, some of them are discussed in this article. A prototyper always looks for the easiest way to bypass same origin policy (if there is a need at all) during development and also the easiest way to make it production ready. Therefore, it is efficient to choose the options that will work without much reconfiguration during your production.