Don't trust database input either.

The database is just another form of input into your program which you should not trust.

You should validate the data coming from your database as much as you do validating the data going into the database.

How do you know the database has not been corrupted, or compromised? Or some script on your website is not validating data properly when it updates the database. Or an DB admin decides to edit the database directly and puts in some invalid data.

What if someone a year from now hooks up another program to the database, which doesn't use the same data validation that you do? Then your program not validating input data from the database will start to fail.

There are many ways data from the database might not be what you are expecting. Not including people putting data in there maliciously. Like if they somehow get your database password. Or if they find an SQL injection.

Executing code from the database surely sounds a bit crazy... right? People execute code when they use python pickle to store data. If for any reason above someone can change your database, then you are allowing them to execute code. So if you are storing pickles - please stop being a mental patient, and change to using a safer form of serialisation.

If you have validation functions, it's fairly easy to reuse that code for validating data from the database. Especially if you are using ORM, MVC, or have a central get() type function.

Unfortunately validating data from the database seems to be a bit too cpu intensive for some people. That, and it's not as big a risk as many other inputs.

Comments

Popular posts from this blog

Draft 3 of, ^Let's write a unit test!^

Is PostgreSQL good enough?

post modern C tooling - draft 6