If your organization is anything like mine, many people don’t know what to make of the AJAX revolution. It seems we are at a tipping point. The web is now saturated with AJAX enabled applications, and development platforms now use these techniques sometimes with out developer knowledge (think .NET and the “god” object). It is not surprising that your enterprise security folks are beginning to take notice.

Last week I attended a training on web security at the SANS Institute where a substantial amount of time was spent on the “problem” of AJAX. I was stunned. The SANS Institute was presenting the security hurdles as so large, so unique, that enterprises should question its adoption. Ever since the introduction of AJAX, the internet has been abuzz with security related concerns, but what for?

I had the fortune of designing the first AJAX application at the AAMC. It was the MCAT Registration system which took a cue from Google Maps and represented test centers spatially and temporally by using a calendar/map combo interface. Registrants could search for test dates and locations via a DHTML interface and then query seat availability with a traditional AJAX call.

This project had numerous difficulties for every predictable reason (new platform, insufficient capacity testing, multiple external and synchronous web services), but amidst flooded database pools and Apache connection timeouts, people were desperate to know why we had used AJAX. These questions were baffling. For my team, it was the equivalent of asking “why did you use images?”

Let’s get one thing straight: An AJAX call is an HTTP request. There is no magical voodoo endowing the browser with mystical powers. The concern for the AAMC was that by using AJAX calls we had caused an explosion of web requests responsible for infrastructure failure. This turned out not to be the case. Our problems resulted directly from true user demand. 15,000 simultaneous requests with no ramp-up was a new record for me, and for our organization.

AJAX is complicated, there is no doubt about it. It is based in a language that most honest web developers will admit they are only somewhat familiar with. Javascript is exposed, insecure, hard to debug, and has single handedly changed the way in which we approach the internet.

When people talk about the risk of AJAX, they are talking about cross site scripting and web service vulnerabilities. This is an issue that is solved with data validation. Distribution of business logic does not mean that data validation doesn’t have to be performed on each layer of your application stack. Validation needs to happen on the client, application server and database.

In the end, it seems our problems are not with the technology, but with the developer. Stewart Twynham summed this up in his article for IT Observer when he said, “the adoption of this new technology appears to make quite sane web developers forget the basics of good coding.”