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.

New Security Threats in AJAX
As mentioned earlier, almost all of the security threats listed for AJAX applications also exist for traditional Web applications. However, there are some points that security-conscious developers and users should keep in mind when using AJAX. XHR requests can be issued asynchronously through JavaScript, exchanging data with the server without any visual feedback to the user. This bears the risk of a malicious application to protocol user interaction without a user's knowledge. Let us take phishing as a possible AJAX attack. In a phishing attack, a malicious page pretends, for example, to be your local eBay home page. While logging into your eBay account you sense that there is something suspicious with the page and don't press the submit key but instead close the window. If an XHR request was sent to the server while you typed the password, then whoever owns the malicious page now owns your password. Obviously there is no protection added to the XHR object that defines which script is allowed to use it. So the only protection is to deal with pages you trust and that identify themselves by a public key.

Another source of potential vulnerability is the ever-growing number of JavaScript libraries that are built to make AJAX development easier. You might be introducing another breach of security when you add libraries to your application without knowing the library developers personally, or without checking that the libraries are secure. Even if these library developers were security conscious, would you know which library functions can be executed from a browser URL field and which cannot? How does the library change its behavior if it is used in conjunction with other libraries? I'm not saying that libraries are insecure and should not be used, rather, that not to care about their security is, in itself, insecure behavior.

AJAX is only at the beginning of its evolution and steadily strides toward real desktop integration. This integration adds more functionality to the JavaScript client, possibly in conjunction with lowering the sandbox in which JavaScript is executed. These are all client security issues - the art of protecting the user client from malicious applications, whereby, in fact, the attack surface for application security has not changed at all.

AJAX Application Security with JEE
The art of protecting an application from its users consists of identifying who those users are and successfully enforcing authorization policies. In JavaScript, nothing can be hidden on the client. This means that any code and object instance on the client can be viewed and modified. There is nothing an application can do today to lock down the browser client. If, as a security conscious developer, you don't control the client, how can it be trusted?

If the client cannot be trusted, then it becomes disqualified to perform authentication and authorization enforcement, and these tasks must to be delegated elsewhere. The Java Platform, Enterprise Edition (JEE), contains a security architecture that meets the security requirements of Web applications, namely reliable authentication, session, and state management; data privacy; and fine-grained authorization. When you use AJAX in combination with JEE, security is enforced on the server on a server-side visual representation of the UI that is rendered to the client. Because no policy is directly accessible on the client via JavaScript, it cannot be changed or modified.

Authentication
The JEE platform provides a declarative and programmatic authentication through container-managed authentication and the Java Authentication and Authorization Service (JAAS). The majority of application servers support a combination of the two so that authentication in JEE becomes pluggable for the administrator to use the security provider of choice. The authentication mechanisms that can be used with AJAX are single sign-on, JAAS LoginModule authentication, container-managed authentication, and Public Key Infrastructure (PKI) authentication. The JEE authenticated user is accessible from the JEE request object so the identity can be propagated to other application layers. An AJAX application user authenticates to the middle tier and the database with a single login. The security context that is built on the server and in the database is not accessible on the client and therefore cannot be modified.

Developers who prefer to use the XHR object method for authentication should be aware of the following limitations:
•  When using basic authentication in XHR, any failed login attempt is handled first by the browser, which pops up its own login dialog to retype the username/password pair. To avoid this, use form-based authentication and check the returned HTTP error code.
•  PKI-based authentication is not possible in XHR. JavaScript does not have an API that allows an application to access the browser certificate store for authentication. Even if there were an API exposed on the XHR object, there would not be any means for the browser to determine which scripts are allowed and which are not.

Authorization
Never bring a knife to a gunfight! The interactive client in AJAX is not a reliable security layer because security policies that are downloaded with data have the potential to be modified in the DOM tree. AJAX is a presentation layer that should not enforce authorization. Instead, the client should reflect server-side security policies when rendering components, such as buttons and text fields.

If this is not convincing enough for you, let's assume security policies on the client were immutable. Because browsers do not provide a security context to be used by JavaScript, the security policy for an object must be downloaded as part of the object or function. If security policies get more complex, as in the case of instance-level security, then the downloading of policies needs to happen frequently. With each policy definition adding a minimum of 8 bytes per character to the message size, a negative performance impact can be anticipated.

Using the Java Authentication and Authorization Service (JAAS) authorization architecture in JEE, fine-grained access control is enforced through JAAS permissions in the context of the authenticated user. A server-side framework like JavaServer Faces, in conjunction with an AJAX UI, can ensure that the client display is rendered so it reflects the security policy enforced on the server. In an end-to-end security example, this could mean that information that a user is not allowed to see is not downloaded to the client at all, which also makes sure the information cannot be found in the DOM.