What replaced CGI scripts is slightly more complex, but also more naturally grows to other use-cases.
In short: I personally don't miss CGI. :)
- Take untrusted input and pass it directly to shell scripts on your filesystem. What could go wrong?
- Executables in cgi-bin were nearly always included in your document root on shared hosting servers.
- File drops and web shells were rampant
- A trivial misconfiguration (not setting +x?) could result in the web server just serving up the source code of your scripts directly to the client. There's your database credentials hard-coded right there at the top of your file now exposed for all to see.
- You had to pay very close attention to resource limits on the server itself to prevent malicious things like fork-bombs
- Apache was a nightmare to configure securely for CGI
The list goes on. I don't miss it at all.
Who passes non-sanitized or otherwise untrusted input to executables, any more than is necessary? Why do you (seem to) believe modern approaches to dynamism are immune when the bulk of user input still comes from HTML forms? How do modern web applications avoid input from untrusted sources?
Same applies to the directory layout of servers they were hosted on. That’s more a lack of server admin competence than a fault of CGI. Was far easier than configuring Tomcat to safely host Java web apps. I recall it being far easier to configure than WebObjects, PHP, Rails, etc.
CGI programs were far from the only form of web application effected by local security implementations. In my experience common gateway interface applications consist of fewer files than something written against Spring, WebObjects, or 99% of server side web app frameworks. Fewer files means less system configuration and less attack surface, no?
As to forking leading to DDOS, that was something that could happen to any forking server, which was pretty much all servers when CGI first came into existence. FastCGI helped address that issue.