It all depends on what you consider to be 'securely'. For instance, you can use an approach where the server prompts for it on startup, and stores in in memory. Although you then don't have the password in a file, someone can still either sniff your network connection, or force a coredump to recover the password. There's also the inconvenience of needing to have human intervention when the service starts.

As a similar alternative, you could store the config in a perl module under mod_perl, and have something else trigger to store the authentication info in the module, which would then be accessible to other programs.

Both of these have the problem that they assume that the whole server is to have access to the database. If you're on a multi-user system, this would be quite bad.

Of course, storing the database connection info in the server is sort of what ColdFusion does. I haven't used it in many years, but up through at least 4.5, the system kept a registry of connection information, and anyone who knew the database connection's name could make use of it.

Other alternatives would be to use Oracle Advanced Security and use some other authentication scheme -- at the very least, ensuring that the user in question can only connect from the web server in question. (even if you use IP filtering of some sort, you can ensure that the user is keyed to a particular host)

You could also store the information remotely, and poll for it, rather than keeping it stored locally ... but you still have issues with how you keep the characteristics of the polling secured, which defeats the purpose for the most part.

I think the important thing to remember is that there is no true 'securely' when it comes to security. You can make things less likely to be cracked, but there is no such thing as unbreakable. If you have to authenticate, it can be sniffed. Even if you were to find some way to pass into the authentication system the path of the calling script, so you could restrict database access to particular directories, I'm guessing there'd be some way to fake it.

You're probably better served by logging access on the database, and spend time reviewing the logs, or writing scripts to parse the logs and look for irregular activity.

Talk to your security folks and your DBA -- odds are, there are other things that you can do to reduce risk -- make sure that the database user had the bare minimum access that it needs, and that you're regularly looking over the logs for sign of improper activity.