For all but the one-person operations, it is recommended that you use separate dedicated boxes for each of web pages, CGI, important databases, and e-mail. This will prevent an intrusion on one of these services from affecting the others. CGI scripts are notorious for security problems, and if you are also running Sendmail (ignoring my advice to run Postfix) then the two in combination can be very bad (CGI scripts will always have direct access to the Sendmail binaries on the system, unless you are running them chroot'ed).
Do Not Trust CGIs
Many CGIs you will find on the internet are quick hacks written by people who are not knowledgable about security. If you are running a site with extreme concerns for security, you may not want to run CGI at all.
Note: You can, technically, have your cake and eat it to with respect to CGI and dynamic web-pages. Always remember that you do have many underlying UNIX utilities at your fingertips ready to lend a hand. For example, you can keep your CGI to a minimum by having it run at intervals and producing static page output that the server then reads. By doing this, you can still have the versatility of dynamic page sites, but with the security (and speed) of static page sites. (This is actually what [Slashdot] does, though, for speed and not security).
You should also note that security varies depending upon the server side language, and some are better than others. We will look at these shortly.
Hidden Form Variables and Poisoned Cookies
Many e-commerce sites store merchandise information in hidden HTML variables. Any halfway knowledgable person could simply download the HTML file, modify it, and then reload it to modify things like prices and weights (for shipping costs).
A similar problem exists for people who rely upon cookies to store such information in. Even if the cookie contains encrypted data, it is possible for a malicious user to break them and modify settings for their nefarious purposes.
