You can choose how much to validate, which is probably more in the former case, but it should be done.
I can't tell you the number of horrors I'm sure we've stopped in (for example) investment banking pricing by avoiding trying to do calculations on junk when the junk was easy to spot. (We also added one or two, eg when one set of interest rates went above 100%, but that's an after-dinner story!)
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.
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.
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?
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.
Ok, that's just plain wrong and absolutely wreckless advice. Everything from software development 101 classes to OWASP data validation can call you on that. If you don't understand why you're wrong, please, please, please stop developing software now until you can understand it.
This is a prime example of the Robustness Principle. https://en.wikipedia.org/wiki/Robustness_principle
What I came up with is this: user name is stored in the database, and some new junior developer in a large team reads it in the backend code, and immediately plugs into another SQL query using string concatenation. BOOM!
But on the other hand, the very same junior developer can forget to sanitize the inputs before storing them (or do it incorrectly), so there.
"Data at rest" means the data that you have no intention of querying soon. Which implies "hot" / "cold" data partitioning, which is usually a good idea. Can be complicated, but commonly encountered in financial backends.
Two layers of encryption can be better than one (if logically and temporarily separated). Encryption algorithms are usually not a problem; credentials compromise or out-of-band vulnerabilities CAN be a problem.
Finally, ANY type of input sanitization is wrong way to do security, and should be employed only as an absolute last resort. Prepared statements provide strong semantic separation guarantees, and you can use ';drop table users; _safely_ as your query parameters. Otherwise you'll be stuck between the requirements corner cases (do you know that legal names can include quotes and apostrophes?) and security requirements, and it is the war that is impossible to win.