One thing that has not been mentioned is permission chaining. Each of my web apps uses its own SQL account and that account is ONLY given permission to run the stored procedures called from the app. Sometimes I'll use two accounts one each for different portions of the app. Because of permission chaining that account does not need permissions to access any tables directly.

1) Encrypt sensitive data

2) Server side validation (versus injection and cross site scripting)

3) Paramertized stored procedures

4) Reduced privilige account from web apps

5) Recordset returned should only contain the minimum required fields (no select * ...)

6) Frequent off server backups 🙂

I think a point that should be drove home very firmly is that you can NOT rely soly on variable validation.

I once read an excellent article describing all sorts of ways to trick single quote substitution. I couldn't find it again but this page offers at least one example.

http://dotnet.org.za/codingsanity/archive/2005/09/28/44998.aspx

On a related note:

Once and awhile I download some neat looking free web app written in PHP. As soon as I see all the dynamic SQL in the PHP code I can't bear it and have to delete it.

Using paramertized stored procedures is:

-more secure

-more performant

-more readable in code

Anyone who thinks its "faster and easier" just to toss dynamic SQL into their code should think again. Once you develop the habit you'll wonder why you did it any other way.