Where should you validate and convert your data?
Try to do as much away from your database server as possible, while still being careful about where your bits are coming from
Just read a great blog on the issue of offloading data conversion tasks from a SQL Server. According to the author, many common code snippets showing how to use parameters to avoid SQL injection attacks frequently are passing strings for objects like data/time objects to the database server, which the database server has to then convert into an object. The database is usually the least scalable part of a cluster, with their usually being:
- One database server
- One or more web servers
- Innumerable web clients
Pushing data conversions as far down that stack as possible is helpful. However, if you have mobile users, you might want to avoid overtaxing the limited mobile processors and not push the data conversion all the way to mobile clients.
But what about data validation? Performing as much data validation as possible at the web client level is a win because it can limit the number of costly (bandwidth and time) transactions between the web client and the web server. But can this data be trusted? This is an important data security issue.
A lead-in editorial about the article talks about lazy programmers not doing enough consideration of the issue of performance. Unfortunately, it didn't fully address the issue of laziness and data security, and the important differences between validation and data conversion.
I don't think the article properly considered this issue, so I wrote this comment:
There is an important difference in the choice of where to do data conversions and data validations: Data conversions can be done at any point in the chain, and doing them away from the database server does make sense.
But data validation, if done in the client, still MUST also be done on the server! Why? Because you should never trust the bits that are running on an untrusted machine (i.e. the users machine.) So while validation at the client can save roundtrips to the server, you must also validate either at the web app, or (preferably also) in the database server. If there is any chance of an input from an untrusted source, (and client code can never be trusted to communicate with the app server unless there is heavy encryption or some other way to authenticate where the bits are coming from), the data must be revalidated on the server side, since you can't be sure it was your client code, or someone else's substitute client or even bot, that is manipulating the app server.
Sources:
Fresh copy to be cached until 2:28:51 AM |
