> It is not the job of the SQL server to prevent SQL injections True. But perfectly valid SQL shouldn't cause the SQL server to be exploitable. And the appli

> It is not the job of the SQL server to prevent SQL injections True. But perfectly valid SQL shouldn't cause the SQL server to be exploitable. And the application has no idea which SQL statements are exploitable. > Similarly, it is the job of Apache to ensure that the things it tells its child processes to do are safe. True. But the unsaid assumption is "safe from the point of Apache". Not "safe from the point of some unknown exploit". So it's reasonable for an application to sanitize what it passes to the shell, by dealing with known and documented issues. e.g. Don't pass "$FOO" in a string to system() and expect it to be treated as the literal "$FOO" string. It's unreasonable to expect that the application know everything about the attack surface of everything it uses. Maybe there's a bug in an SQL library which causes the application to crash when a SELECT statement contains the text "crashme". This text is valid SQL, and it is entirely unreasonable to expect that the application "sanitize" such text. In the same way, environment variables are strings. It's a bit surprising to discover that bash will execute code contained in random environment variables.