The Achilles' heel of Ajax is security. Despite its usefulness, this programming approach introduces a new vulnerability into Web sites and user interactions: The execution of downloaded JavaScript code on the client.

A multitude of security problems followed on the heels of Microsoft Visual Basic developers' use of ActiveX controls in Web applications. There was repeated opportunity for imposters or uninvited intruders to substitute their own executables in the download and run them on unsuspecting users' PCs.

"The whole notion of passing around lots of JavaScript is awful," warns Gary McGraw, CTO at Citigal, a software risk management consulting firm. The idea that a Web application depends on server downloads of executable code to a user's PC "leads to much more code-injection risk than one would want," he says. "Think SQL injection has been a problem? Just wait. Ajax is just asking for it."

But Fima Katz, CEO of Ajax integrated development environment supplier Exadel, says the issue is careful design, not the interactive technology. "You're running somebody's code in your browser. There's no question you're more exposed," he says, but if you do it right, you don't have any more problems than with non-Ajax systems.

Keep the client minimal, with restrictions on what the JavaScript is allowed to do on it. If the application is open to the world, he says, keep the business logic downloaded to the client to a minimum and require most of the business logic to be executed on the Internet server, which can be more easily protected against intrusion and code injection.

Return to the story:
Ajax 101: From Toolkits To Strategy, How Companies Can Put It To Use