9) Old security threats get a second exposure

If you listen to the pundits, Ajax may appear to produce more attack surface, but it really isn't any less secure than traditional Web-application development environments, because the HTTP inputs to the trusted server side are the same — headers, query string and message body. If implicitly trusting client-side code and entered data is not verboten already in your Web development group, however, Ajax may push things in that direction.

Cross-site scripting (XSS) isn't a vulnerability new with Ajax; it is just more common, especially if an application allows state data to be manipulated with JavaScript. HTML input should be disallowed in most cases, and HTTP Only Cookies should be applied immediately to reduce cookie hijacking and other attacks via XSS.

Cross Site Request Forgery likewise isn't new with Ajax, but if your application developers aren't checking the HTTP Referer (sic) header and managing sessions properly within Ajax applications, you've already been open to it, although it might be worse now.

Hackers, like developers, now are more interested in using and abusing JavaScript, which increases the potential for exploits. Network professionals should make sure developers are aware that client-side code can be manipulated even with obfuscation in place, so data inputs should always be filtered and sanitized, Ajax or not.

10) Abide by same origin for your protection

On the positive side of security, JavaScript's same-origin policy (SOP) is fully enforced in an XMLHttpRequest-based Ajax application. This policy makes sure that scripts cannot talk to domains outside of those from which they are issued. From the developer's point of view, this can be quite annoying because it means that pages served, for example, from ajaxref.com can't talk to a URL hosted on www.ajaxref.com; even if it is the same machine, it isn't the same exact domain. DNS equivalency doesn't matter here; it is a string-check employed by the SOP.

The SOP will severely hamper a developer's ability to perform some Web-service efforts on the client side as well. Clearly the best approach is to use a proxy on the server to bounce requests to other servers and combine the results. However, many Ajax developers attempt to break the same-origin restrictions. Using the <script> tag as a transport instead of the XMLHttpRequest object introduces dangerous trust assumptions, and that leads to the origin of much of the concern about overall Ajax security.

Now, with such browsers emerging as Firefox 3 and Internet Explorer 8 employing native cross-domain request facilities, there is certain to be more trouble on the horizon. As is the case with Java's security-sandbox concept, SOP restrictions are introduced just to keep developers from destroying security. Go around such safeguards with extreme caution.