I'm banging my head on my desk here.. you have completely changed your argument.
?
You said you must add multiple checks to ensure the input is filtered. THAT is superfluous.
??
For your informatrion, as you obviously haven't worked it out yet, intval is a perfectly safe way to ensure the input is clear of all 'dangerous' characters, unless MySQL have suddenly decided that some Int char's are special chars..
Trying to be as clear as possible. Intval is not escaping - it escapes nothing. Intval is Input Filtering, as it removes/negates an input value which does meet a predefined rule, i.e. must be an integer. Escaping and Input Filtering are two different things. When I mention escaping I am in no way referring to input filtering...if that's whats somehow gotten confused...?
In many applications you will filter input and validate, use it in your business logic, then perhaps write to the database. At the database level you escape (for XSS you might escape elsewhere of course). If IF and E are in separate layers it makes immediate sense for each to act independent of the other - Data Access couldn't give a toss about what's filtered so long as it can escape for any dangerous SQL Injection enabled characters and vice versa.
So input comes in - its a string supposed to be numeric. You filter and hit it with inval(). All is well with the world. You pass this to an SQL. It gets escaped. The Data Access class doesn't care whether you forgot a filtering rule, or it got edited by a confused developer, or was bypassed through some later change - it just escapes on the basis it's taking zero chances with user input.
At no point in my example or anywhere else is only some input escaped
What does inval() escape? I thought it just returned an integer value?
if you care to read up on the function intval() you will realise that any char's not equivocal to an Int are removed, i.e. if it aint 0-9, it doesn't get returned.
That's not escaping... And I'm perfectly familiar with intval() thank you very much... Please don't make assumptions about my PHP knowledge.
So.. if you know the input should be an int (and ID field is a perfect example..) then using intval is a perfectly acceptable method to filter, validate and escape, all in once step Wink After all, in an integer value has nothing to escape with a slash, does it? So what good does using mysql_real_escape_string or any regex do? Wink
Because Input Filtering != Escaping - they're two discrete tasks. They may be complementary, but in a well separated application they're not even close to being substitutes. I'll reserve a exception for procedural code whic is very rarely well separated like OOP practices.
Escaping + Input Filtering > Input Filtering, i.e. increased security (for whatever reason).
Code, such as escaping an integer value, after it has been filtered by intval() is superfluous, thus not optimal.
Its also less secure though - which is the point of the argument methinks, or methought.
BTW - you do not 'prepare' for developers cock ups. If they are going to remove the intval(), they could do any manner of cock ups, which none are my 'fault' (as that is what you seem more worried about).
You do - if you have to listen to the client whining at you because you fell into a support contract following your app development

I'm guessing type hinting will meet with similar disapproval...sigh.
I've never, ever seen a developer add in extra code just to satisfy the incompetence of possible future developers, because, like I said, it is poor practice to include extra code just for this purpose. This is what the documentation and comments are for.
So you will document that you don't escape *all* user input entering the database? Fair play in that case.

I know what you are driving at - I just can't agree. If I pull on my auditors cap for a moment all I see is the equivalent of deliberately lowering security over an essential area because an extra puny mysql_real_escape_string() call is not "optimal".
Defense/Security in Depth Principle promotes the ideal of never relying on one single security measure when two or more are implementable. Why? Because if one fails, you'll have another line of defence. It's a simple entirely reasonable concept.