This article provides an introduction to some of the security threats associated with AJAX technologies, particularly when used within mashup scenarios, and then offers a list of recommended best practices.
Understanding the Same-Origin Policy
One of the foundations of Web security is the "same-origin" policy, which is widely implemented by Web browsers, including the most popular ones (e.g., Internet Explorer, Firefox, Safari, and Opera). Browsers implement the same-origin policy as a protection mechanism in order to isolate Web applications coming from different domains, under the assumption that different domains represent different originators. As a result, if applications in multiple windows or frames are downloaded from different servers, they will not be able to access each other's data and scripts. In the context of XMLHttpRequest, the same-origin policy is intended to control an application's interaction with remote servers.
However, the same-origin policy does not offer complete protection for several reasons. It's possible to bypass the same-origin policy in many ways. We'll illustrate some of these later.
Furthermore, even if a Web server is from a trusted domain, it might not be the originator of all of the content, especially in the context of Web 2.0. For example, an enterprise portal server, Web-based mail server, social networking site, or wiki may be trusted, but the contents they host may include input from potentially malicious third parties, which might result in cross-site scripting (XSS) attacks (described later).
Ways to Circumvent the Same-Origin Policy
There are many techniques for getting around the same-origin policy. Here are two Web application features that can be leveraged by malicious developers:
• JSON and the Dynamic Script Tag: As part of the same-origin policy, browsers do not allow XMLHttpRequest to communicate with external servers. However, browsers do allow <script> tags to reference URLs from different domains as shown below:
• AJAX Proxy: An AJAX proxy is an application-level proxy server that mediates HTTP requests and responses between Web browsers and servers. AJAX proxies sometimes allow Web applications to bypass the same-origin policy and access third-party servers using XMLHttpRequest.
Common Attack Techniques
Malicious code can find its way into a Web application in many ways. Here are three attack techniques.
• Cross-Site Scripting (XSS): XSS is a technique in which an attacker injects a malicious fragment of code into an otherwise benign site. One form of XSS attack exploits vulnerable Web applications that display input parameters back to the browser without checking for the presence of active content in them. An attacker might lure victims into clicking on the URL, as shown below:
+ document.cookie; </script>
Suppose that trusted.com hosts a service that has a search feature that posts back the search results together with the keywords that were entered. If the search application does not filter the special characters [such as the less than (<) and greater than (>) symbols] in the URL, the content of the <script> tag will also be inserted into the user Web page, and, as a result, send the document cookie to the remote server evil.com. (Note: This is just one example of an XSS attack.)
• JSON Hijacking: JSON Hijacking builds upon CSRF to provide malicious sites with the ability intercept ("hijack") confidential data delivered in simple JSON format. JSON Hijacking takes advantage of a feature in some browsers that allows script to override the core language's object setter routines.
Mashups Can Broaden the Attack Surface
"Mashups" or Web applications that combine data from more than one source provide additional opportunities for security attacks if proper security policies are not in order. Mashup applications often allow arbitrary third-party mashup components. If a malicious site is able to entice mashup users to embed their mashup component, and if the mashup application does not offer sufficient protection, then the user and the mashup application's Web site are vulnerable.
Recommended Best Practices
Here are some techniques that can improve the security of AJAX applications:
• Add an input value check: Most XSS attacks exploit server-side vulnerabilities by injecting malicious scripts that a vulnerable server will send back to the client. Therefore, server-side input validation is the first step toward protecting Web applications. The two main types of input validation are blacklisting (all characters in the blacklist are filtered out from the input) and whitelisting (only allow an approved list of characters). Blacklisting and whitelisting are not foolproof, but whitelisting is generally considered the more effective option.
• Escape special characters: For example, change the less than symbol (<) to <, the double-quote symbol (") to ", and the single-quote symbol (') to '. Some programming languages provide useful built-in functions to escape special characters (such as htmlspecialchars and htmlentitiesfunction in PHP).
• Use vulnerability checking tools: Security experts have developed tools to detect insecure programming practices, often called "vulnerability checking tools." A common vulnerability detected by such tools is forgetting to call an appropriate sanitation routine to filter potentially malicious input.
• A more in-depth version of this article can be found at
• The OpenAjax Alliance maintains a wiki page about AJAX and Mashup Security, with links to various technical resources such as articles and software tools, at the following URL,
• Some of the material was first published by IBM developerWorks at