AJAX is not secure
AJAX is the new Hot technology concerning web application. It allows the client to do much more than it used to and to achieve a much better user experience.
AJAX is based on XmlHttpRequests that the browser creates while the page is presented on the browser. The client does not know that under the cover so many requests are being sent. Ajax is a java script technology running mostly on the client side and on the server the following question arises: will the average AJAX-enabled web-application be able to tell the difference between a real and a faked XmlHttpRequest?
The answer is NO. AJAX is a client side technology and we all know that the client should not be trusted.
This makes AJAX a much more difficult technology to protect. We all know how difficult is to bring application security to traditional server application. For AJAX it is double the effort.
AJAX is advancing rapidly and new frameworks are introduced frequently but none can secure the AJAX application in a reasonable manner.
From a business and an architectural point of view unfortunately today we have to make a tradeoff. Security versus User Experience.
Proper design can use AJAX in a sandbox. This means less sensitive areas of the application can enjoy AJAX but around the sensitive business and information an "AJAX Firewall" is built. For example there will be no AJAX enabled Web Service that exposes sensitive information.
If you do need to implement some AJAX remember that AJAX enables new XSS capabilities and so server validation must be much more strict. Not only the body of the http packet must be validated but all of its headers. Never trust a third party. AJAX applications fetch information from various untrusted sources such as feeds, blogs, search results. If this content is never validated prior to being served to the end browser, it can lead to dangerous cross-site exploitation.
With AJAX, a lot of the logic is shifting to the client-side.
This may expose the entire application to some serious threats.
The urge for data integration from multiple parties and untrusted sources can increase the overall risk factor as well: XSS, XSRF, cross-domain issues and serialization on the client-side and insecure Web services, XML-RPC and REST access on the server-side.
Conversely, Ajax can be used to build graceful applications with seamless data integration.
However, one insecure call or information stream can backfire and end up opening up an exploitable security hole.
These new technology vectors are promising and exciting to many, but even more interesting to attack, virus and worm writers.
To stay secure, first answer the question is AJAX really needed? Then make sure it lives in a sandbox and third make sure your developers are paying attention to implementation details and taking security into consideration.