I'm working on a project that would use bash and FastCGI to create a pseudo-CMS.

Are there any kind of security concerns to watch out for within FastCGI itself over a well written bash script (for example buffer overflows, and the like)?

2 Answers 2


Buffer overflows aren't really relevant to bash. Something you do need to take care of is input validation. You need to validate all user input to prevent any form of injection.

You should have a look at the OWASP Testing guide as they cover all sorts of vulnerabilities relevant to web applications. It's largely language independent although the examples might be more focused on real programming languages designed to write web applications.

P.S. I really need to know: Why are you writing a CMS in bash?

  • 3
    I do need to know to ? do you loose a bet ? or maybe a dangerous psycopath has kidnapted your familly and he forces you to do so ?
    – Kiwy
    Jan 8, 2014 at 8:52
  • No I'm just wondering why he made such a choice, it's quite uncommon to choose bash. Jan 8, 2014 at 9:02
  • Because it can be done. Awk has one, this is how SDF does their site, and biggest reason of all this is also for a wargame challenge which has only busybox, fcgi, and ssh on the server. So I wish to eliminate all points of entries other than the ones that contestants are meant to find. Jan 9, 2014 at 1:58
  • Also to further enlighten readers on why bash cgi, think of how node.js and php operate they abstract the CGI layer and hide it away internally to the interpreter. Writing a shell script that uses fastcgi[key here is fastcgi is leveraged to implement cgi functions] then one has better control and understanding of the gears that make the web work. The analog is asm to c++ where bash fastcgi scripts is asm and node/php is c++. Apr 28, 2016 at 16:13
  • If you are good at shell scripting and just doing a personal project that needs an HTTP interface, CGI bash is so easy to prototype in. I'm doing something similar for my personal CMS Jun 24, 2021 at 5:59

Yes. Do not write CGI scripts in pure bash. Bash is one of the worst languages if it involves untrusted input. After the shellshock incident, people looked at bash more carefully and noticed it was absolutely packed with security issues. Sadly, bash isn't just bad because the interpreter itself is insecure, though it most certainly is. The very paradigm of the language itself was not built upon a secure foundation, so the scripts, even when following best practices, are notoriously hard to get right. While it's usually fine for command line use, using it for CGI scripts is a recipe for disaster.

If you really, really have to write it in pure bash, I strongly urge you to both run extensive static analysis on the script, as well as dynamic analysis (fuzzing). A few static analysis tools you may want to look at are ABASH, shellcheck, and checkbashisms. The third is not a security tool, but it can help test for code correctness. You should be completely familiar with best practices for shell scripting, which isn't just limited to "quote your variables".

You should also be sure to limit the damage the CGI process can do to the rest of the system. Make sure permissions are tight, and chroot your httpd process. You might also want to make use of mandatory access controls, like SELinux if you are on a RHEL-based distro, or AppArmor if you are on a Debian-based distro. Make the most use of PAM as possible to limit the process' resources. Subscribe to various security-related mailing lists so you can upgrade bash ASAP whenever new vulnerabilities come out. You may also want to install auditd and configure it to extensively audit the system, as well as setting the script to -x, and exporting the trace to logs. This will help you identify exploitation attempts much more easily. These are all generic server hardening techniques, but you have to apply them to the fullest extent if you are going to willfully use something like bash for CGI.

  • Good answer and honestly I wish more php/nodejs/(insert 3rd gen web centric programming language here) developers thought more like this. It's even a driving idea behind using bash cgi scripts. Though I did play with shellcheck and found its easy to break. It found rm -rf / but not find / -exec "rm -rf {}" and even eval "$(echo "cm0gLXJmIC8=" | openssl enc -base65 -d -)" was seen as validated (should have been echo '...' instead. One thing you did miss was also implementing cgroups and chroot jails, no I don't mean docker alone, to further isolate the running process from the OS. Apr 28, 2016 at 16:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .