I do know some specific items that you should test though.

Near the top of the list is that you should try entering ' and " into nearly every form field looking for SQL injection attacks. Add various kinds of invalid output. Then turn JavaScript off and walk through the same tests (client-side checks only are useless). Then from some kind of scripting interface attempt to submit large data samples and see what happens.

In general any kind of exception that you get which does not look like your bad input was specifically caught and properly handled is a red flag. For instance if a ' gets a 500 error or (far worse - you don't want production to advertise useful debugging info) it gives a database error about bad SQL then you probably are wide open to SQL injection attacks. Even if you have no idea how to turn the error into a complete formatted dump of your database, rest assured that plenty of people out there do.

Of course add malicious input. For instance anything that touches the filesystem or system commands might be open to your entering in paths with things like ../../../etc/passwd. Oh, you check for that? Well how about .\\./.\\./.\\./etc/passwd? Etc. Assuming a Unix system, what about seeing if you can enter commands using backticks like `this`. It is never fun to come in to work and find that someone successfully executed `rm -rf /`. OK, they didn't destroy the machine since it was from the web account, but you don't have a website left...

Moving on, you need to check the overall layout of the site. For instance there is absolutely no need for the database to be talked to by the outside world. Nothing should be left with default passwords anywhere. Any port which does not have a specific reason to be open should be closed. (For instance if you allow people to make DNS requests of your webserver, then you have to worry more about new bugs in your DNS server.) In general everything should be locked down and there should be someone whose job description includes keeping track of and applying needed security upgrades.

Or maybe testing that is out of your remit and you just need to focus on developer mistakes. Well then, find out what language the application was written in and find out what things should be done for that language. For instance if it was Perl then code should have been written with strict and taint checking turned on. (Other languages don't offer taint checking, such a pity.) With PHP, verify that it is a recent enough version that people can't set variables by passing them as parameters. With any language, check that errors do not display debugging stack traces. (Why help people debug their attacks on the fly?) etc.

There is more. A lot more. Any list that I gave you is sure to miss something that I as a developer would notice looking at code. And I miss tons of stuff because my job is developer, not security expert. I'm only aware of a handful of security problems that have come to my attentions as good development practices.

Are you sure that you don't want to hire someone like [link|http://news.netcraft.com/archives/2003/01/01/ecommerce_security_testing.html|Netcraft]?

Cheers,
Ben