That sounds like BAD validation that needs fixing, not an excuse not to do any.

Some US sites still won't let me in because (a) they insist that I must have a middle name or (b) screw up the hyphen in my surname.

Many sites and payroll systems assume that everyone has a surname. Never mind its character set and ordering.

Even if you don't make these assumptions you don't need to accept a binary gzipped GB of zeros or worse in a name input field.

Designing a _good_ validation system (to reliably discriminate between "good" strings and "bad" strings, including all corner cases) is really hard, error-prone, not future-proof (standards change) and might be even theoretically impossible in some cases.

Some basic sanity checks are useful, of course. But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks prevention.

> But it is not a good idea to use input sanitization as the only (or even main) method of injection attacks prevention

Can you define what you mean by "input sanitization"? Because in my mind, a prepared statement is doing just that. You say what part is your SQL, what part is your user input, and you let the DB adapter sanitize the input to build the final statement. You aren't writing sanitization code yourself, you're leaving it up to a library, but that's still what's happening. Or do you have a different term for what's going when a prepared statement routine converts user input into SQL-safe strings?

I never said:

1) That it was easy to do right: that's why we get paid.

2) That it was an excuse not to do other checks elsewhere: defence in depth is key.

Anyhow, I hope that we're really furiously agreeing.