Nice example, but not all are insecure. For example, the second one here is:
$result = mysql_query('DELETE FROM saves WHERE id = '.(int)$_GET['delete']); $result = mysql_query('DELETE FROM saves WHERE id = '.(int)$_GET['delete']);Casting to int is not a general purpose escaping system, and further, if you miss even one of these your entire application can be trashed.
Using mysql_query at all is a sign there's something severely wrong with your application.
And also, doing the cast inside the sql statement makes it difficult to see. It should be done, if at all, outside the query where it's obvious to anyone looking at the code that this is something that should be paid attention to.
If you're inserting a value in a database, you always, always, always use the proper escaping mechanism. No exceptions.
That's why using a library with a reliable, well-defined, easy to use escaping system is absolutely imperative.
This is an actual, serious problem which I would note in a code review, as opposed to the int thing which cannot, as far as I can can tell, ever lead to an exploit or malfunction which would have been avoided by using a named escape function in this code. If anyone can think of a specific example to prove this wrong, please say so.
While there's nothing technically wrong with the example given, I might argue that since that won't work in all cases, it might be better to enforce a more rigorous policy of SQL query cleansing, or using bound params. Although this example is so simple I might not.
Then again, the fact that $_GET is even available at the location the query is taking place means this is most likely a type of design that I abhor, that PHP makes easy. Put actions in functions or methods, and then call them.
That doesn't mean PHP doesn't deserve some stick, it does, but most of it's current reported problems spawn from backwards compatibility. Nobody should be using mysql_*, they should be using prepared statements via PDO.
They could solve this by deleteing all the functions you're not supposed to use, but a whole bunch of legacy PHP would stop working. I'm fairly sure this would illicit more hate than the current method of slowly deprecating.
IMHO, neither are good design choices, as one couples the program to HTTP too tightly (and not in a sane way), the other leads to crazy spaghetti PHP as the control flow can be affected by global variables set (or received from the user) far from where they are used.