Secure ajax applications

Since alot of the coding in AJAX applications is done in javascript on the web browser, it is only natual to do user-input validation on the browser itself (client side). This could be a major security risk in AJAX application. 

Imagine we have a bank application where the user is able to transfer money from his account to a different one. Naturally, you wouldn't want to allow the user to enter a negative value in textbox where he inserts the amount of money to transfer (You can't give someone -100 dollars). with AJAX, it might seem natural to write a client-side javascript code to make sure the value enterted is positive. 

However, when submitting the form data back to the server it is very easy to intercept this data and change it (Proxies, MITM, etc...). So somewhere between the browser (client) and the server, the data has been modified to a negative value.

That is why it is VERY important to re-validate sensitive information on server side. Once the submitted data has already arrived to the server, it is much more difficult to intercept change it.

In addition to the previous answer, all the usual concerns about writing secure applications apply:

Is there validation of the data submitted once it's on the server?

Are you checking the refer(r)ers, so that people can't manipulate your data with their own scripts from the outside?  They can see lots of your code, remember.  You want to try and keep the actual logic of database access on the server side handler, because exposing that stuff to a blackhat is like putting up a sign saying "hey, come and get me".  Just because javascript doesn't let you do cross domain stuff, won't stop someone writing a php or perl script to do it, now that they know your API.  Know where your input is coming from, all the time.

If a user changes a parameter in a link, could that give them access to someone else's data?  Are your authentication procedures secure enough to prevent that?  The fact the code is all out there in public makes this a much bigger area of vulnerability than doing things server side.  Are you checking often enough that who you think is requesting a blob of data is in fact who really is requesting it?  Know who is making the request, every time.

Are you stripping input data of things like slashes and quotes, to guard against things like SQL injections?  Know that data going into your server side application is safe.

Are you inadvertantly setting yourself up for a DoS attack. It's pretty darn easy to splatter widgets all over a page that do dynamic database lookups, are you sure you accounted for scale, with caching where possible?  I'm thinking of things like the page where a form I filled in had one input for my country, and then hit the database and looked up the states based on the country I chose. That works fine for one person, what happens when there are 1000 filling in the form? and it's hitting the DB again for the post code, and area codes for phone numbers....  What happens when there are 10000 users?)  One of the issues with AJAX is that it's actually really easy to do all that lovely smart stuff, but the area codes aren't changing and could as well be handled without a DB lookup.

Basically, don't trust anything, assume all incoming data is tainted until you are sure it's not, and validate and double check every input. Just like you normally would, writing any web app, except more of it.

It's very illuminating reading up on the myspace worm the guy who made it, Samy, wrote out in detail exactly what he did and how here: http://namb.la/popular/tech.html as a first hand look at two things: how much work myspace does proofing their incoming data, how much work someone will be willing to put into getting around it.

except considering something when writing secure web application, you have to test a lot to ensure the security of your web application.

I suggest you check the OWASP Testing Guide, there writes a lot about the security of web application in the SDLC