Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

One of our developers has an opinion that all client data should be validated before using it. Even non-input data.

Say, our web service has an internal protection against database injections.

Examples: machine generated codes, various integers, indexes, calculated values.

We use ORM (Django). As I know there is a next approach in Django: validate only values entered as primary strings (usually via web forms).

For example: is there any reason to create validation rules to validate numbers if we know that there is 500th error (if the data are wrong) in the beginning of handling request? I think no. But probably I'm wrong.

Do my position requires to be changed?

share|improve this question
Any client data can be tampered with unless you're absolutely certain your client is unhackable and your communication is secure... which is unlikely. Therefore, validate everything that comes from the client (if trusting the client is not an option). – MetaFight Feb 18 '14 at 15:04
What is "non-input data"? If you can receive arbitrary data from an external source then yes, of course it should be validated. It may not be malicious, but even the most trusted client could typo or have the data corrupted in transit. – Phoshi Feb 18 '14 at 15:05
@Phoshi The validation is not protection against hackers. It's only a verification that data corresponds to required types. – sergzach Feb 18 '14 at 15:07
@sergzach: It's surely both? As I say, it may not be malicious, but mistakes happen. Clients have bugs, users do invalid things, networks go wrong. None of that requires "hackers" to enter the equation. – Phoshi Feb 18 '14 at 15:29

You should ALWAYS validate ANY data that is inserted to your database, either before or after it is actually inserted into your database program. Preferably both, if practical.

Of course, we should write software correctly the first time, everyone should pay their taxes on time, and no one should ever cheat on their spouse. Just because something's a good rule doesn't mean you need to blindly follow it.

Your other developer is right, in that client data should be validated, if it's given as an XML or JSON or CSV file or as a database vendor's binary backup format. Some of these will make the validation easier (XML + binary backup), but you should always have a plan for "what if this data is corrupted or given entirely wrongly."

At the very least:

  1. Have a backup of your database you can smoothly restore to if you find the database corrupt post-import.
  2. Don't import into production right away. Run the import in your development or test environment first.
  3. Check record counts in the imported file, pre-import database, and post-import database. If they do not clearly match, rollback the import until you can explain the discrepancy.

For bonus credit, teach whomever's sending you data how to run a CRC on a file, and have them provide that via separate cover.

share|improve this answer

The client can temper with any data they send you, so you have no guarantee that your own client-side code has generated the non-input data. However, you should not be obligated to stop a client from burning themselves when they try to hack your system.

Ask yourself this - is invalid data in those non-input fields a problem only for the client, or is it a problem for your system and/or other clients?

If it's a problem for the system and/or other clients, then by all means validate it. You don't want other clients to suffer from hacking mistakes, and you don't want your server to get hacked.

However, if it's a problem only for your client, you don't have to go out of your way to solve it. After all - they are hacking your system. You want to protect your clients from mistakes when they use the UI or web service you provide them, but if they try to find backdoors and make mistakes it should be their own problem.

For example, if you client-side code collects locale data from the clients machine so your server can correctly generate time&number formats and convert to the proper units when rendering the pages. The client hacks your registration form and send the registration data directly via HTTP request, but they got the locale format wrong and now they get dates in the Gibberishian calendar and lengths are displayed in Pounds.
I say - it's their own freaking problem for hacking your system!

You can be extra nice and validate that data for them, but nobody should blame you for poor hacking-support...

That being said - you should really make sure that this is the case before deciding not to validate that data. For example, if the client posts data that is being parsed based on his locale and displayed to other clients, you'll want to validate that locale so you won't ruin that data for the other users.

share|improve this answer

Personally, I think the client application, it must provide an ideal environment to perform properly the functions of the software solution (which also includes the back-end).

is there any reason to create validation rules to validate numbers

Why the web application should allow me to make mistakes?

The validation in the client is not about security system, because obviously does not have the possibility to play that role, but must be considered as a solution of usability.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.