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.
