Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the past, Apache used to serve cgi files from cgi-bin folder only, and it was always advised to avoid putting executable files in public folders. However, today's webservers fairly serve executable cgi file from everywhere.

What is the security risk for serving webpages directly from executable cgi files? For example, what is the risk for where executable file of hello.cgi is in the root (public) directory? (comparing with a non-executable PHP file of hello.php)?

Of course, cgi scripts are practically served via FastCGI to persist the connection, but does it have an better security too?

share|improve this question

In short, separating CGI files, which are often scripts, makes it easier to ensure that the web server will never mistakenly return the text of the script to the client instead of executing the CGI and returning the results. If the script "source code" is revealed to the client, it may expose sensitive information, such as embedded database connection passwords or just information about how the script executes that could be abused by an attacker.

For example, the entire /cgi-bin directory is usually configured to execute files and never to return content. If you edit hello.cgi and leave an editor backup file hello.cgi~ behind, the server should never return that file as content if /cgi-bin is configured correctly. On the other hand, if that backup file is sitting in a normal web root that serves files, then the magic mapping of ".cgi -> execute" won't take effect for the hello.cgi~ file, and the server may therefore return the content of hello.cgi~ instead of executing it.

share|improve this answer
I totally agree with the risk issues you quoted, but can't we overcome by include the actual code? I mean having hello.cgi with no code except including the actual code which is outside the public folders. Thus, upon a failure in webserver, nothing will be exposed except the full path to the actual script (which is inaccessible). – All Sep 26 '12 at 18:28
If by this you mean having a file shell in the webroot which simply includes another file outside the webroot, you could do that, but it's more complex than simply segregating your scripts into a /cgi-bin directory with strict controls. – gowenfawr Sep 26 '12 at 18:50
Also, to complicate the matter, newer languages like PHP permit you to mingle code and content within the same file, which was a major impetus for the shift away from /cgi-bin to inclusion of scripts within the webroot. So another aspect of the answer is "...and it used to make more sense, in the old days." – gowenfawr Sep 26 '12 at 18:52
I am not against the idea of cgi-bin, but the point is that I use nginx not Apache, and the implementation of cgi-bin is not common in nginx or I am not aware of that. – All Sep 26 '12 at 18:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.