If CGI param()s are tainted (and I believe they are) and you're using the bind params, then I think SQL injection is the least of your worries. It will probably complain if you don't think to check the tainted stuff. And if you test poorly and untaint and it gets passed to DBI ... it probably won't matter because the DBI quoting and bind params should take care of it automatically. I don't believe javascript can change the problem space with respect to SQL injection.

However taint and DBI probably won't help with things like cross site scripting and the remote root hole on some random service you didn't know you had running (if applicable).

...further to testing user input/tainted_values:
- use regexes to include the most sane data rather than excluding illegal characters etc. - be especially vigilant about any email generating script/form, as these are easily hi-jacked by script kiddies to deliver their spam - all the other CGI safety precautions apply: e.g. don't read/write anywhere else except safe directories, remove any path entries from your environment, call any binaries with full pathname, etc.

Cross-site scripting attacks are dangerous because they can trick legitimate users/clients into performing actions they do have authority for, but don't want to do.

So you still need to worry about anything that can influence the client - like html/javascript in input etc. Usually, like quoting with DBI, HTML-escaping all output should go some way, but there are more complex issues.

http://www.owasp.org/ is a good resource if you're serious about web security.

You asked about SQL injection attacks. The protective steps you've described protects against those *only*.

If you then take what's in the database and send it out in HTML, then you're publishing someone else submission, and that's a whole different problem.