Is "filter input, escape output" still valid with PDO

Question

I've read this before "filter input, escape output" but is filtering input really needed when I use PDO with PHP? I thought with PDO I don't need to filter input because the prepared statement takes care of sql injections. I think "escape output" is still valid, but is "filter input" still valid?

Answer 1

Yes, it is still valid.

Filtering is not about preventing security vulnerabilities, it's about not populating your database with garbage. If you're expecting a date, make sure it at least looks like a date prior to storing it.

Escaping output is about preventing security vulnerabilities (namely XSS or Cross Site Scripting).

So yes, both are quite important and are totally unrelated to SQL Injection (although a fair number of developers still confuse filtering with escaping for SQL queries and hence can still be subject to vulnerabilities)...

Answer 2

Depending on what the data you're saving is, yes it can still be valid.

For example, let's say you have a comment box and a user writes a message containing HTML markup. In this case you would often want to remove the said HTML markup from the comment text, even if it ended up being escaped (afterall, it probably won't look very nice).

There are other cases too, like if you have a phone number field, you might want to filter it so it's in the specific format your application uses and so on.

Answer 3

Always filter user input. Always. Maybe you're protecting against attacks, or maybe you're performing business rule validation, etc. Keep in mind that there is no technology or procedure that will prevent all attacks, only attacks it was specifically designed to prevent. SQL injection isn't the only problem to avoid.

Answer 4

As per sql-injection and security, if you're using PDO properly with bind variables, no you don't need to sanitize. But as Jani pointed out, depending on the data you are saving, such as a text field which doesn't allow html, you might want to sanitize your data, or if the field should be a number, running parseInt() on it or something. But this isn't going to be required to security, but for your own database sanity. It's kind of ugly when someone tries to put html in a comment and you spit it out and you see > < etc.