ith the popular adoption of AJAX techniques mushrooming on the web today, real-life security issues were sure to follow, as illustrated by the Yamanner and MySpace worms. The debate over AJAX security now rages, with widely differing opinions. Just google "AJAX security" and you will receive more information than you can sort through—let alone absorb—in a week. Never mind making intelligent strategic decisions based on it and producing secure AJAX-based applications as a result. However, to help you jump-start your research, CGISecurity has conveniently organized some AJAX security content here, and the Open Web Application Security Project (OWASP) has begun to assemble some formal documentation here.

The Common Themes of AJAX Security
As you wade through the plethora of available AJAX security information, you will discover three common themes:

1. AJAX, or more specifically, the use of the XMLHttpRequest object (XHR), does not corrupt the web security model on its own, provided that a strong security architecture is defined and enforced during application development.
2. Defining and enforcing a strong security architecture is a non-trivial exercise, and virtually none of the multitude of JavaScript-laden AJAX libraries that exist today will help you do it. This is an exercise left to the developer—don't blow it, or blow it off for that matter.
3. Most obviously: the client is untrusted, SO DON'T TRUST IT!!

Let's assess what each of these themes means to an enterprise that is motivated to leverage the benefits of AJAX, but needs to maintain high levels of security.

AJAX on Its Own Doesn't Corrupt Web Security
This is the good news. It means nothing about the use of XHR in JavaScript is fundamentally insecure. In fact, XHR is restricted to on-domain HTTP requests, which makes it safe to use provided proper access control is established. And if the contents of an XHR response contain sensitive data, the whole connection can be secured with SSL, so you essentially have a secure foundation on which to build.

From a security perspective, calls in the industry to extend XHR to allow cross-domain requests are ludicrous, as this would compromise the security foundation. The concept of an autonomous JavaScript client freely accessing multiple domains in some sort of SOA/mashup architecture cannot be achieved in a secure fashion, and should be discarded.

Enforce a Strong Security Architecture
If you have security at the foundation of AJAX, then building secure AJAX applications is just a matter of ensuring that you develop your applications in a secure manner. The dos and don'ts associated with this are wide ranging and have been enumerated and described in articles all over the web (at WhiteHatSecurity.com and OWASP.org, just to name a couple). So, it is not whether you can in theory, it is whether you can, and will, in practice.

Don't expect your favorite JavaScript library to provide inherent security. You need to be conscious of security issues at every step of development. In fact, depending on which libraries you use, you may not be able to ensure security at all. Frameworks that rely on client-side interpreters and/or dynamic script injection are particularly vulnerable to attack, and they could introduce inherent insecurities to any application that uses them. Also, because of the complexity of most JavaScript AJAX libraries, security audits and thorough security testing may be next to impossible.

Don't Trust the Untrusted Client
It is as plain and simple as it can be: the client is untrusted so don't trust it. This means that you cannot trust client-side validation, you cannot trust client-side state management of sensitive information, and you cannot trust client-side business logic. But what do most client-centric AJAX libraries promote? You guessed it, all of the above. So if you are going to be security minded, you might not be able to fully leverage the features of your client-centric AJAX technology of choice.

Intertwined with all of this is the blurring of development roles. Client-centric AJAX approaches have already blurred the lines between application developers and web designers, and now the AJAX developer clearly is going to have to be a security expert as well. This blurring of roles compromises proficiency and stifles creativity at all levels. And of course, when you consider all aspects of cross-domain expertise, skill sets start to go from scarce to nonexistent.

All in all, the challenges involved in delivering secure AJAX applications appear to be fairly daunting. What is really needed is an approach that provides inherent security, and maintains role distinction so that security experts can ensure security, while developers and designers focus on creative application solutions.

Editor's Note: The author, Stephen Maryka, is Chief Technical Officer at ICEsoft Technologies Inc., a vendor of AJAX-based technology products. We have selected this article for publication because we believe it to have objective technical merit.