in reply to Re: How to answer "Perl is not secure" objections?
in thread How to answer "Perl is not secure" objections?
As for securing Perl more on the server, a perl with a small default @INC can be done easily enough. There are taint mode and Safe.pm to help with boxing in data and code. The installed modules could be kept minimal. Perl supports chroot (although only root can do that).
It should be possible (I'm not saying 'easy') to run both Apache and perl (or Apache with mod_perl) chrooted in the first place if security is at such a high priority. That's a pretty language-independent way to help with security. Things such as ulimit and a good IDS help no matter the language, too.
One thing to keep in mind is that the ability of the programmer to do something doesn't mean it's possible for the site's end user. Any system written in any language which does stupid things with end-user data poses a security risk, no matter the sandbox restrictions. XSS proves the server itself doesn't even have to be vulnerable to cause a security issue -- it can create a security issue for the user even if it is entirely protected.