This section of tutorial tutorial explains Cross domain Ajax calls and Same Origin policy in web browser. All modern browsers today are following the same policy.

One of the current trends in web applications is communicating with the content and functionality from two different sources. Over the last few years, Google, Yahoo, Flickr, YouTube and Amazon has allowed developers to implement in their own applications, by opening up of formerly proprietary APIs with simple one line calls to their APIs. That enables developers to the features such as adding photos, maps, videos and playlists, comments, likes etc.

Also, in business application sometimes we are forced to create the similar meshups, by making the web service calls to different IPs. In the case of web services, they are always called either with SOAP or HTTP-GET/POST requests and return information in the same way may be using XML, JSON or any other format. They are designed to be called from other domains, and in sometimes it is a contradiction to prevent them being called this way. The client applications developed has to make cross-domain web services calls, and mostly they use Ajax calls.

Browsers security restriction imposes the cross domain web Service calls using Ajax.  Bowsers have the same-origin policy exists to prevent malicious use of resources.  Browsers by default don’t support to make cross domain Ajax calls. If we make so, it returns the following error:

XMLHttpRequest cannot load URL. Origin is not allowed by Access-Control-Allow-Origin.

Visit the below link for more details on browser security policy: Same-origin policy.

How to get around this limitation?

There isn’t a single answer to this question; here we will see the different work around and current most popular techniques, what several techies are proposing.

1. Cross domain proxy

This is one of the most common approaches. Your script calls your server; your server makes the call to the remote server and then returns the result back to the client.

There are some definite advantages to this approach. You have more control over the entire life-cycle. You can parse the data from the remote server; do with it what you will before sending it back to the client. If anything fails along the way, you can handle it in your own way. And lastly, you can log all remote calls, with that you can track success and call failures.

2. Cross domain JSON/ JSONP

For this approach, the remote server needs to be set up to handle this. It needs to handle an additional parameter i.e. a callback function. The response back will load a JSON object as a parameter of the callback function you specified in the request.

A conventional JavaScript program might request this URL via XMLHttpRequest, to the URL

This JSON data could be dynamically generated, according to the query parameters. And it might receive the response in JSON format like this

{"Name": "User1","Id": "USRGRP111","GROUP": "GR10"}

In JSONP the src attribute in the The received payload would be:

 parseResponse({"Name": "User1","Id": "USRGRP111","GROUP": "GR10"})

More on JSONP and security concerns visit Wikipedia

3. Cross domain using Flash

Flash is much like Ajax, and by default you cannot again make cross-domain web service calls. Work around to this us we can enable the capability by placing a special XML file on the remote server to accept requests from other domains.

Visit the link to understand more on making cross domain calls from flash

Limitation: The great limitation to this technique is that the browser must need to have Flash installed and enabled.

4. Disable web security policy

This approach works as a temporary fix for the application only for development purpose. Here we can disable that security policy by opening the browser with “–disable-web-security” command.  This disables it for the entire browser, until you restart it. Steps to disable the browsers security policy:

  1. Right click on the Chrome.exe
  2. Add –disable-web-security command to the target path. It should look like

C:\Users\<User Name>\AppData\Local\Google\Chrome\Application\chrome.exe –disable-web-security

5. Disable web security policy using frameworks available

ACD framework:

This article is about: JavaScript,


A blogger, a bit of tech freak and a software developer. He is a thought leader in the fusion of design and mobile technologies. He is the author of Xamarin Mobile Application Development for Android Book (, DZone MVB and founder of


Please note: We reserve the right to delete comments that contains snarky remarks, offensive or off-topic. To know more read our comments policy.