Treating all data that comes from outside the program as suspect or even downright hostile is one of the most important rules for security if not the most important. It's one that often gets forgotten when programming or configuring an application, though.
Any coding guidelines that help with robustness or maintainability help with security, too. If something's not robust and crashes when it's not a target of an attack, someone can crash it on purpose as well. They may even be able to crash it in a predictable enough way to exploit it. If code's not maintainable, then fixing security issues once they are found will take longer. Being security conscious is a good coding practice, but good coding practices in general help with security, too.
I realized since my post above that since PerlMonks is a great source for discussion of all things Perl, I probably should have included some node references. I did a little searching around the Monastery for other security discussions, and some of the topics you mentioned came up. As usual, the threads are generally more valuable taken together than any single node from a thread by itself.
- Is it Secure? is a good general discussion from 2002 on formulating and following good security guidelines and some references to particular ones.
- Paranoid about web application security is a discussion of how to know if an application (a web app in this case) is secure.
- Security techniques every programmer should know is Juerd's attempt at starting a secure coding tips guide, going so far as to directly ask for further advice from other monks in the replies.
- tinita asks Is your web application really secure? ("CSRF")
- How can I secure MySQL & CGI? asks about securing a CGI application's database login info
- Cookie based authentication: Is it secure? is a discussion about the security issues of cookies as a web authentication mechanism
- Guide to Building Secure Web Applications and Web Services leads to wonderful resources like the top ten classes of web vulnerabilities as of 2007 and a list of guideline documents for all sorts of security issues from the SANS Institute.
- Essential CGI Security Practices is cjf's handiwork.
- In Stay aware of security tilly starts a good discussion about security and vigilance.
- pjf and jarich have courseware about programming securely in Perl at http://perltraining.com.au/courses/perlsec.html which I found through Perl Training Australia's Security notes released. I'd contact one of those monks for licensing questions, as it says available for personal use.
- In Ideas Wanted for Perl::Critic Security Policies jthalhammer starts a discussion about what Perl::Critic could do to automatically assess some security issues.
- Security Standards is grep's announcement to PM that an accomplished IBM security auditor has released some secure programming and testing guidelines, complete with links to them.
- Ovid brings us a (OT) Security Rant, although I'm not sure how "OT" it is.
- tilly advises us to always Stay aware of security.
- merlyn bemoans security issues and several people reply with good references about security in web site design, or lack thereof where he (merlyn) reminds us that secure and non-functional is better than insecure and functional.
- talexb organizes some testing of placeholders for preventing SQL injections at Preventing SQL injection attacks: Placeholders are enough for MySQL, Postgresql and SQLite.
- Speaking of SQL injection, I mention SQL placeholders as a preventative for code injection in a flawed RDMS in Yet another reason to use DBI placeholders.
- At UTF8 related proof of concept exploit released at T-DOSE Juerd informed the monks of a class of bug in some Perl code that uses Unicode support slightly wrong in a way that will sometimes work but also allow an exploit under certain versions of perl.
- The tutorial Using Temporary Files in Perl mentions some of the security implications surrounding temporary files which are common to any language.
- Preventing XSS talks about cross-site scripting, which is another language agnostic security issue.
- Finally, one of the most comprehensive nodes and associated followup threads on coding standards ever to grace PM is On Coding Standards and Code Reviews by eyepopslikeamosquito which covers all sorts of guidelines for writing code including some security issues. It also gives a nice bibliography of other guideline and policy documents from other organizations regarding coding for security, robustness, and maintainability.
- In My coding guidelines Abigail-II isn't as verbose as eyepopslikeamosquito, but the guidelines are a good study in maintainability even if one may disagree with certain individual points.
As you say, though, the simple security issues that often aren't paid any attention should be addressed first. Get the low-hanging fruit that is most likely to allow the easiest route to exploitation, then move up the tree.
Update 2009-04-8: Thanks to ambrus for spotting a grammatical error. s/(secure and non-functional) (than insecure and functional)/$1 is better $2/;