Okay, yes, a considerable amount of blame lies with apps and frameworks that have security holes. But here's the thing: make the runtime secure /by default/, so that -- if you really want to run Wordpress, you have to uncomment the PHP configuration labeled "this is extremely hazardous and will likely result in your machine getting compromised" and I think you'll find those third-party apps and frameworks cleaning up their act in a hurry.

Many of those features are completely harmless if used correctly. By itself, exec() doesn't cause your machine to be compromised. It is a valuable function that every scripting language should have. (Would you like Python to disable os.exec* by default just to make websites more secure?) Besides, incompetent developers will always find a way to make vulnerable apps using even the most benign features. The only way to make a runtime secure against fools is to allow nothing.

There is also the logistical problem that if the default runtime can't run popular apps such as WordPress, people will simply switch to a broken runtime instead of cleaning up WordPress. This is a particularly big problem in shared hosts who need to make their service compatible with everything or risk losing business. It's been difficult enough to get them to adopt PHP 5.3.

On the other hand, safe_mode, register_globals, magic quotes, etc. can and should be disabled by default. Good news: The PHP team is finally getting around to deprecating them. Also, I use dotdeb's FPM packages on my servers, and dotdeb's default configuration tends to be pretty good.

"Would you like Python to disable os.exec* by default just to make websites more secure?"

Yes! Under no circumstances should you ever be spawning new processes from your web application on the fly, ever. You should be using trusted communication to an existing worker thread that is fired up on application start and then never touched except for IPC (think Akka), or trusted communication to an existing process on another machine separate from your web / app server that you can start or stop yourself, separate from the web process.

"Besides, incompetent developers will always find a way to make vulnerable apps using even the most benign features."

Very true; however, you can make it extremely difficult to do so, and you can effectively limit the damage in case of breach. That's what most of the configuration is, from the parent article. Stop someone from being able to write an arbitrary file on the filesystem, by telling them to either store a blob somewhere, or sending data to S3, or whatever, and it will be extremely hard to overwrite existing application code that gets re-interpreted every time it's updated.

"There is also the logistical problem that if the default runtime can't run popular apps such as WordPress, people will simply switch to a broken runtime instead of cleaning up WordPress."

Disagree-- the onus is on Wordpress to keep up with the current version of whatever language they decide upon. When PHP version X disallows re-compilation of scripts on the fly without some sort of notification or server restart, some people and hosts will stay on version X-1, sure, but that's going to be really hard when every distribution starts packaging version X. Wordpress, PHPBB, etc., will need to go through some development pain, but ultimately those packages will wind up being more secure.

The reality is that these kinds of articles shouldn't have to exist. I'm even a little shocked at the Java community, because Red Hat's documentation on "How to Secure JBoss" actually exists, too-- remove jmx-console, remove web-console, and limit access to the http-invoker and jmx-invoker services (and that's it). What Red Hat should be doing is to have a "production" configuration that does all these for you.