> PDO is awesome but requires deeper level of understanding (for a beginner), which may increase the frustration and may end up returning back to the mysql_query and co.
At the same time I understand why it would be more confusing for newbies.
In a language that already has string interpolation you're telling them to use a crappier custom version of string interpolation that's safe for databases.
But if the example above uses PDO underneath, then it's not just string interpolation though I think. It's sending the query and the parameters separately to the database, which is creating a "prepared data object" to plug the parameter values into.
Do you know any good PHP database frameworks that help you build up the query programmatically?
Over the years, we built one in-house at http://qbix.com/platform/guide/database because we couldn't find one. It does things like sharding out of the box, because it's able to understand the query's criteria and target it to the right shards.
As an interesting side note: Laravel's AR ORM (=Eloquent) is built on top of the Query Builder so you can leverage Query Builder with AR if you know what you're doing. Can also lead to big problems if you don't realize the possibilities and the caveats.
Here has been discussion in another comments about overusing ARs for trying to achieve too complicated things that'll lead to DB performance problems. As stated elsewhere here, AR is good for CRUD operations but after that you should use Query Builder or plain SQL to achieve the more complicated cases.
People who want to do string concatenation will continue to do so no matter what we tell them. At some point, we have to educate users. Giving them an easy-to-use alternative is a step in the right direction.
Why not have the obvious API call for making a query only accept constant strings? You can still have an escape hatch for the rare cases where an expert needs to do something fancy, but hide it well and make it scary and you shouldn't have many problems.
Right, well, "constant strings" don't really exist in scripting languages, and before you mention objects that encapsulate them, what's to stop developers from building them elsewhere before passing the string to an object that encapsulates them?
Chicken and egg.
Education is the security strategy that pays forward the most.
There's no technical reason the language couldn't make it so that string literals can be identified at runtime.
There are several good ways to put a stop to SQL injection. Better education is one, better APIs is another. There is no reason to just give up on the idea of using SQL queries directly because of injection attacks.
I'm not sure what your point is here, because what I'm advocating is precisely to make it easier to use parameterized queries and more difficult not to.
Yeah, that's basically why I wrote EasyDB. https://github.com/paragonie/easydb
Teach people to do things this way rather than concatenate strings, say goodbye to SQL injection vulnerabilities.