In the name of security, I am going to disagree with most of your suggestions. One of the main failings of software developers is that they have no clue what security is. I include myself in this category, although I have personally spent quite a bit of time trying to work on this failing.

One would assume that DBI was being used from a CGI or mod_perl. Storing the password in a file in a location not directly accessible via HTTP isn't actually better than storing the password in the CGI itself, as the CGI is executed, and is not available in plain text. If anything, moving the password to an alternative location makes it more difficult to control security since there are more paths that have to be accessible that need to be properly maintained.

Better than configuring your database server to only accept requests from a specific IP address may be only allowing requests from a UNIX local socket. This protects one from the hopefully small windows where port rules or routing rules may not be 100% bullet-proof.

Directing all database access to a middle-tier process that prompts for a user provides obfuscation, but does not really improve security. Anybody could connect directly to the middle-tier process. Although obfuscation is not to be under-estimated as a method of reducing the probability of an attack, in this case, it comes at the direct cost of efficiency and maintainability of the application, and is not reasonable. In the case where the middle-tier process lives on a separate box, this may be even worse, as it guarantees that the middle-tier process is waiting on an open socket. Unless the middle-tier process is using identd or some other mechanism of testing the privileges on the 'trusted' web server, *any* user from the web server could connect to this off-server process.

Eventually the only practical solution comes down to controlling access to the web account, and making the CGI read-only to the web account. Also, the SQL server should be configured to limit the abilities of the account hard-coded into the CGI to only those queries specifically necessary. For example, if possible, INSERT might be allowed, but UPDATE or DELETE might not.