There are several security issues with having an Ajax enabled application. Some of them are traditional web security issues that are magnified because of Ajax, and some a new issues. Here are just a few. I refer you to my BlackHat presentation Ajax (in)Security for more info.

Old Issues:
Issues:Ajax applications have a larger attack surface.

Results: Its easer to hack your webapp. Traditional applications have a relatively few number of forms or other parts that accept user input. We already do a poor job protecting these (just look at Full Disclosure any given week). Some web apps accept file format input, and we do a really bad job securing that input (see numerous PNG/JPG attackers, WMF, ZIP attacks, etc). Ajax increases yet a 3rd type of application inputs, Web services. Most Ajax requests are destin for a web service that woudln't exist if the app didn't use Ajax. As a whole, web services are rarely protected because most programmers don't think of these are inputs, they think of them as functions. This is really bad when retrofitting a traditional application to an Ajax application. Before, the web service or function was hidden inside your enterprise with no way for the client to directly call it. With an Ajax app, large parts of the applicaitons API are now publicly exposed and are rarely secured.

Issue: Ajax applications are very complex. They are written in multiple languages, the code must work on multiple platforms/OSes, and they are multi-threaded.

Results:Ajax applications are much harder to debug and test than traditional applications. JavaScript is highly dynamic, loosly typed, and can add new exection paths as well as edit current execution paths in a program. This means most JavaScript errors are runtime errors and its very hard to examine all possible paths the program will take. This, coupled with the the asynch nature of Ajax means most Ajax apps contain deadlocks and race conditions that can be exploited.

New Issues:

Issue:Your application straddles the network and exists on both the client and the server.

Results:Attackers can see data types, return types, function names, and program flow of your application by analyzing the plaintext JavaScript. While you should push not business logic to the client, most people do and Ajax Frameworks like CPAINT/"Atlas" make it easier to make this mistake by abstracting a control. Programmers don't know (and don't want to know) how much of a control is on the client and how much is on the server. CPAINT makes it very easy to "export" or "share" a PHP function so your client code can call it directly. I've seen apps in the wild that have a webservice you can send PHP or Perl to that simply get past to an eval statement.

Issue: Ajax is something that on the client, not the server. Websites cannot turn it on or off

Result: Ajax has amplified the damage XSS attacks. Ajax allows XSS to make hidden, asynchronous HTTP requests that the browser will automatically add the necessary cookies and HTTP auth to. The XSS has full access to response as well. Even sites like Yahoo's webmail that don't "use" Ajax per say can still be contacted by an HTTP request that Ajax makes. Ajax has directly lead to the creation of self propagating XSS worms.

Issue: The Server cannot tell the difference between a request made by the browser in response to a user event (clicking on a link) and a request made by the browser because JavaScript told it to.

Result: As a user, you cannot prove beyond a reasonable doubt that you did or did not issue an HTTP request. The effects of this in a financial application are frightening.