Home/ Questions/Q 241455
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T20:45:18+00:00

(Note: these two questions are similar, but more specific to ASP.Net) Consider a typical

  • 0

(Note: these two questions are similar, but more specific to ASP.Net)

Consider a typical web app with a rich client (it’s Flex in my case), where you have a form, an underlying client logic that maps the form’s input to a data model, some way of remoting these objects to a server logic, which usually puts it in a database.

Where should I – generally speaking – put the validation logic, i. e. ensuring correct format of email adresses, numbers etc.?

  1. As early as possible. Rich client frameworks like Flex provide built-in validator logic that lets you validate right upon form submission, even before it reaches your data model. This is nice and responsive, but if you develop something extensible and you want the validation to protect from programming mistakes of later contributors, this doesn’t catch it.
  2. At the data model on the client side. Since this is the ‘official’ representation of your data and you have data types and getters / setters already there, this validation captures user errors and programming errors from people extending your system.
  3. Upon receiving the data on the server. This adds protection from broken or malicious clients that may join the system later. Also in a multi-client scenario, this gives you one authorative source of validation.
  4. Just before you store the data in the backend. This includes protection from all mistakes made anywhere in the chain (except the storing logic itself), but may require bubbling up the error all the way back.

I’m sort of leaning towards using both 2 and 4, as I’m building an application that has various points of potential extension by third parties. Using 2 in addition to 4 might seem superfluous, but I think it makes the client app behave more user friendly because it doesn’t require a roundtrip to the server to see if the data is OK. What’s your approach?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Without getting too specific, I think there should validations for the following reasons:

    1. Let the user know that the input is incorrect in some way.
    2. Protect the system from attacks.

    Letting the user know that some data is incorrect early would be friendly — for example, an e-mail entry field may have a red background until the @ sign and a domain name is entered. Only when an e-mail address follows the format in RFC 5321/5322, the e-mail field should turn green, and perhaps put a little nice check mark to let the user know that the e-mail address looks good.

    Also, letting the user know that the information provided is probably incorrect in some way would be helpful as well. For example, ask the user whether or not he or she really means to have the same recipient twice for the same e-mail message.

    Then, next should be checks on the server side — and never assume that the data that is coming through is well-formed. Perform checks to be sure that the data is sound, and beware of any attacks.

    Assuming that the client will thwart SQL injections, and blindly accepting data from connections to the server can be a serious vulnerability. As mentioned, a malicious client whose sole purpose is to attack the system could easily compromise the system if the server was too trusting.

    And finally, perform whatever checks to see if the data is correct, and the logic can deal with the data correctly. If there are any problems, notify the user of any problems.

    I guess that being friendly and defensive is what it comes down to, from my perspective.

    • 0