1. Where do you place your Perl modules/scripts?
2. Where do you place your database log-on info and is it encrypted?
3. What is considered "best practice" if that can even be answered?

The answer to all three questions is: "It depends"

The first question I'd ask myself before answering any of those questions is what are the risk factors that I am trying to mitigate? What am I trying to protect and how "valuable" a target is it?

The next factor I am going to look at is what facilities I have at my disposal to help boost my security stance.

For instance, the old hosting provider I had for my personal website had the account's directory structure such that there was one directory tree for any files associated with my account. In other words any file I put in my accounts file space could potentially be in the path of the web server serving up pages and possibly be exposed to a browser.

My current provider has my file space such that there are actually two file trees and even my HOME directory is structured so that the web files are a subdirectory under HOME. That means I can place my home grown Perl modules somewhere out of the way of a browser not to mention any configuration files. The result is none of my CGI scripts ever have information like database logins in the source code itself.

So to answer question #1, if I have my druthers I keep the CGI scripts with just the essential code in the cgi-bin. That's just how it has to be unless I have control over the webserver and can tailor it. I keep modules that those scripts are dependant on elsewhere out of the normal browsing path and do something like use lib qw@ .... path goes here @; to point to where their at.

To anwer #2 I keep my database login info in a configuration file (again outside the browsing path) and lately I've been using XML::Simple to read it in but there are other ways.

I know there are monks out there that will disagree with this statement but "best practice" is a) in the eye of the beholder and b) depends on many factors. One of those factors being what facilities you have available to you and another being to what degree do you need to be cautious. Websites that I am working on that involve financial data are going to be sites that I'm much more security concious of than say my dog club's web page announcing upcoming events. Keep in mind that no matter how secure you set things up all you are doing is raising the bar you are never going keep someone out who is sufficiently motivated and/or knowlegeable of how to circumvent security.

Last thought: there are some things you do have to consider in your coding that you really didn't ask about in the list above.

• Data validation Make sure any inputs you process aren't going to do things you don't expect.
• File uploads Treat with care. There are good ways of handling them and bad ways and make sure you understand what you are doing before working them.
• Injection attacks Make sure you understand what they are, how they work and avoid code that is suseptible to them.
• Remote executions Web applications that allow random users to execute things on your machine is a really bad idea. If you insist on doing that make sure to take appropriate precautions to avoid malicious activity.