Security in AJAX
Unlike traditional Web applications that have a more or less static user interface, AJAX applications have an active client that uses the browser’s native XHR to fetch data from a server. There are two major risks to the browser regarding client-side JavaScript: browser bombing and cross-site scripting attacks:

• Browser bombing is the client version of a denial of service (DoS) attack. During this type of attack, the client is kept busy with JavaScript processing, such as running endless loops that fill up an array with content. When the client consumes all computing resources, the desktop hangs.
• Cross-site scripting has two facets. The first one, which was already mentioned, is where a script downloaded from one domain tries to access properties of a page downloaded from another domain. The second facet is where developers fail to validate user input, resulting in a JavaScript that is executed when the user-added input is rendered on a Web page. Imagine a discussion forum that does not encode JavaScript content or check for SQL keywords. A hacker could, for instance, add JavaScript that performs a runtime attachment of an image tag to the page in which the src attribute references a uniform resource locator (URL) on the hacker’s server. The script could, for example, append the client’s cookies as a request parameter. The application user does not recognize these changes because the HTML does not flag a missing image as an error.

While client-side security protects the end user from the application, application security protects the application from the user. Protection includes enforcement of authentication, authorization, and data privacy.

Though XSS and SQL injection attacks can be handled in AJAX on the client, you should not miss the opportunity to enforce the same policy on the back end in an additional layer of defense. In traditional Web applications, request filters implemented on the HTTP server (or in the application configuration) performed pattern searches using such things as Regular Expressions on the incoming request to detect technology keywords of JavaScript and SQL. In addition, filters were used to replace special characters with their encoded equivalent, such as when replacing < with &lt;. AJAX applications are like traditional Web applications, so the same security design patterns apply to them.

Security design patterns are recommendations of best practices to mitigate the risk of an identified threat. Patterns that exist for Web applications include defense in depth, limited view, least privileged access, checkpoint, and roles.

In addition to best security practices, there exists a sensitive balance between usability, performance, and security that needs to be considered when building AJAX applications. It is easy to risk vulnerabilities simply by annoying end users with too many security-related interruptions when they are working in an application. Such users soon turn into hackers on their mission to find a more convenient way to work with an application. AJAX applications are based on client-side JavaScript and only provide a minimum capability to maintain client-state in cookies and page variables. Unless the AJAX application is built on top of a server-side framework that manages the application state, AJAX applications risk losing state upon page reload and navigation, adding a need to re-request user security credentials.

The XHR Object
The XHR object is an Application Programming Interface (API) available in all modern Web browsers that allows scripts to asynchronously and synchronously perform HTTP client functionality, such as submitting form data or querying data from the server. The only exception to the list of browsers supporting XHR is Microsoft Internet Explorer (IE), versions 6.0 and below, which use the XMLHTTP ActiveX control. XHR is the AJAX-enabling technology. All the following HTTP request methods that are available for traditional Web applications can be used with XHR: POST, GET, HEAD, DELETE, and PUT.

The following security-related functionality and limitations exist for the XHR object:

• The format of the content that can be exchanged between the XHR client and the server is restricted to plain text and XML, which is a useful limitation that prevents the download of binary executables without the user noticing.
• While native JavaScript cannot access request headers, XHR provides this ability to AJAX, allowing it to exchange information (such as session keys) with the server without encoding it as part of the request URL. According to the latest W3C working draft for XHR [W3C], not all HTTP headers are configurable to avoid misuse.
• One of the exposed methods of the XHR object allows developers to authenticate a user to the server before accessing restricted resources. The XHR authentication is handled by the server-side Web container that obtains the username and password pair from the request. By default, the username and password are not encrypted but sent in clear format. AJAX developers can use JavaScript encryption libraries that exist on the Web to protect the password, assuming that the server knows how to decrypt the string before performing the authentication.
• The XHR object does not provide an API to handle secure communication using secure socket layer (SSL) technology. Instead, the XHR request uses the same protocol for security that is used to download the containing page. This limitation is the result of the same origin policy enforced on the server, which treats http as a different URL than https. This means that, for all sensitive communications, AJAX has to use a page reload to switch protocol before sending the information.