If you don't use prepared statements with PDO, i still don't see this as PHP's problem. This is a unqualified programmer problem.
refer to: http://www.phptherightway.com/#databases
In the case of MongoDB, a system that was designed to make SQL injection attacks a non-issue, in which they were a non-issue in other languages, were noticed several years later to suffer from SQL injection attacks in PHP and PHP only.
The cause is that the language, behind programmers backs, could let users supply a data structure where it looked like you'd only get a string. And would only have had a string in other languages.
PHP is not the only language with problems like this. For example Ruby on Rails about a year ago had a series of bugs that were due to a similar design flaw. But this type of mistake has, for years, been more common in PHP than in any other programming environment. And PHP programmers like you who think that they can just follow a couple of well-known guidelines for databases and be safe, who fail to understand when you are told directly that the problems are bigger, are a big part of why PHP continues to have these problems.
When programs volunteer to parse things in possibly unexpected ways, you tend to open up security holes where most people wouldn't expect to find them. In that situation, no matter how much you jump up and down and point the finger, the convenience of parsing is itself a real problem.
You've been pointed to a case where real programmers had real security problems stemming from PHP's willingness to parse when programmers using PHP did not expect PHP to do that because other environments don't. You fail to see that this is a problem with PHP, and only think of it as a problem with programmers.
Your willingness to accept that programmers should need to know more than they should, combined with an unwillingness to rethink your beliefs when presented with evidence that this has lead to real problems, is a perfect example of my point that PHP, "has attracted a community that fails to recognize these things as problems."
But i still say, if you expect a string from a query (address bar) but you don't type-check it before using it somewhere, it's your problem not php's. (by the way i'm a ruby programmer in my 9-5 work)
Figure those things out, and then you will understand why I think that PHP is worse for security than other languages.
Yes, programmers need to RTFM. Security isn't free. But PHP makes it much, much harder than it should be. And does so with a base of users who are not prepared to do it well.
If you want to get real security, you don't get it by simply saying, "Bad developer!" You do it with layering defenses. Developers who know what they are doing, using APIs that are clearly defined, with languages that do not introduce unnecessary potential security issues, with development practices that catch issues, with monitoring that notices stuff, and so on and so forth.
Yes, developers should RTFM. But if RTFM is the beginning and end of your thinking, you've got disasters waiting to happen. And the results are abundantly clear with PHP.
Now I'm done with this conversation. You are missing what should be a pretty basic and obvious point. PHP makes security harder than it should be. Not impossible. But harder than it should be.
Anything sent to a web app via HTTP is user generated content. You can't assume it is ANYTHING.
In PHP the exact same approach turned out to be a security hole because if the user supplies the right input you get a data structure that is meaningful to MongoDB.
As you say, you shouldn't assume anything about user generated content. But PHP's willingness to parse that input and turn it into something the programmer didn't expect to see often means that user generated content is harder to deal with in that language than you should reasonably expect it to be.
For several years if you followed the examples in the MongoDB docs, you wouldn't have known you had to, because the people who wrote those docs didn't know you did either.