With 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.
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
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 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.