CGI on a VPS: enabling and securing CGI in Apache and Nginx

Apache CGI configuration

To enable CGI in Apache, ensure mod_cgi or mod_cgid is loaded (a2enmod cgi on Debian-based systems). Add a ScriptAlias directive in your virtual host: ScriptAlias /cgi-bin/ /var/www/cgi-bin/. This tells Apache that requests to /cgi-bin/ should be executed as CGI scripts from /var/www/cgi-bin/. In the Directory block for that path, set Options +ExecCGI and AddHandler cgi-script .cgi .pl .py.

suEXEC is an Apache module that runs CGI scripts as the file owner rather than as the Apache process user (typically www-data). This provides process isolation between virtual hosts: a script owned by one user cannot affect files owned by another. Configure it by setting the User and Group directives in the virtual host and ensuring suEXEC is compiled in. The trade-off is increased configuration complexity and stricter file ownership requirements.

Nginx and CGI

Nginx does not execute CGI scripts natively. The standard approach is to install fcgiwrap, a minimal CGI-to-FastCGI gateway that accepts FastCGI connections and executes CGI scripts for each request. Install fcgiwrap (apt install fcgiwrap on Debian/Ubuntu), configure it to listen on a Unix socket or TCP port, and add a location block in your Nginx configuration that uses fastcgi_pass to send matching requests to fcgiwrap with the standard FastCGI parameters.

fcgiwrap re-forks a new process for each CGI request, giving you the same isolation model as standard CGI while fitting Nginx's FastCGI upstream model. It is not as fast as a persistent FastCGI application, but it is simpler than converting existing CGI scripts to a persistent server model and gives you a working CGI environment on Nginx with minimal changes to existing scripts.

Security hardening on a self-managed server

On a VPS you control the full server stack, which means you own the security configuration. Restrict the CGI directories to a dedicated user and group with minimal permissions. Disable the ability to execute scripts from upload directories explicitly. Keep the Perl and Python interpreters updated through your distribution's package manager. Consider running CGI scripts in a chroot or container if the threat model justifies the added complexity.

Use a web application firewall or mod_security on Apache to add a layer of input filtering in front of your scripts. This does not replace proper validation inside the scripts, but it can catch common attack patterns before the script ever runs. Log all CGI requests with access and error logging enabled, and set up log monitoring to alert on unusual patterns like repeated 500 errors or large numbers of requests to a single CGI path.