Thanks for your thoughts, adrianh! Some responses...

For example the compromised script could spin off another process that sits their doing a dictionary attack on your database

badly set permissions could allow the script to rewrite itself, etc.

In some ways a mod_perl server would be more secure. Set it up to only service a single request per-process. You still save on startup time, forks are cheap (definately cheaper than starting up a separate CGI process and loading all the modules needed), and a compromised service would have to restart Apache to affect future requests.

Attacks are possible with a mod_perl script that aren't possible with CGI, since it has access to the listening socket, the scoreboard, and other internal Apache data structures. For example, this bit of mod_perl will intercept some future requests, but isn't possible under CGI:

# FD #16 is the listening socket on my Apache
# You can use lsof on an Apache child to find yours.
open(LISTEN,"+<&=16")
  or die "Couldn't open LISTEN socket: $!\n";
while(1)
{
  accept(ACCEPT,LISTEN)
    or next;
  print ACCEPT  <<EOF;
HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 10
 
Snarfed!
EOF
;
}
[download]

I'd have my W3 server talking to a separate applications server on another box using a very thin application specific protocol that only supplied just enough functionality for the W3 application to do what it needs to do. You hide most database-specific exploits away on the other box, and have something that you can apply fine grained security controls too.