I'll consider you talking about validations that could be made exclusively on the client side. There are validations that are inherently impossible to do without the help of the server. They are cases that depend on information that the client does not have and that the information is not in a definitive state.

Web

I'll talk about using the web even though the conditions are good for any type of client. On the web validation on the server is critical, in other types of clients where the source code is not available, where you have control of who has access to the client and the network is closed this need is not so important. Of course, you may always have a risk in leaving the verification on the client only, but you must understand the environment where the system will run, the culture where it will be used. For all there are exceptions . In some cases, the risk that is duly assessed and considered low can be rewarding. Still, it is not desirable that you leave all control on the client side.

Why should the validation be on the server?

The main reasons have already been stated in the other answers, I will summarize:

• The data coming from the client is never trusted , they can be altered / falsified in default of your client's code, even though you take some precautions to make it difficult.
• There are no guarantees that you can validate effectively in all situations. You have no control over the environment where your client is running .

You may have problems with:

• Data consistency
• malformed data
• receiving malicious data
• exploiting system crashes
• server overload
• Unplanned failures
• things no one has predicted yet

You have to validate everything , even if you use ready-made framework tools to delegate this validation. It is common for the programmer to forget to validate some things. For example, it validates the entry date, but forgets what is not obvious that it may be wrong in some specific situation. It does not think like the hacker / cracker that will try to defraud your system. You need to validate if the information will not open security holes in the system. But beware of the tools that seem to validate well but only do something superficial. Example: ValidateRequest of ASP.NET. It is not wrong, the mistake is to use it thinking that it solves all your problems.

Validating on the client only

You can do a validation on the client only if it alone does not matter to the system. It may be something that facilitates the UI experience by giving additional information to the user, but the information is not important if it is correct and especially if it is not sent to the server. If the information will not be persisted and will not influence other operations there is no reason to validate on the server side. But this is rare. It is only good to be aware of this not to adopt a single solution blindly.

Validating on the server only

In some cases you need to ask if you should really validate on the client side . There are cases that validate only on the server may be the best choice. It does not mean that you should expect to submit all the data to validate everything at once. You will validate given the data as they are being made available by the user through a validation service on the server on demand. But even doing this, when the data is finally submitted, the validation must occur again (unless there is no new submission and the previously submitted data is already used, but I doubt if this always works). The only advantage of this approach is that you avoid creating validation in a different language (use only C # and do not need to have the validation written in JS as well, making it easier to DRY , although with WebAssembly this may change). It has the obvious disadvantage of generating more traffic and processing on the server.

Validating data being sent by the user only in javascript is not enough because of:

• If the user disables javascript, you may end up with invalid data on the server

• If the user is malicious, he can send invalid data to the server

• In the case of an MITM attack, validation on the server would be more difficult

• Server validations make a site less susceptible to malicious robots

In summary ... it's worth cautioning against all these unknown agents, doing the validation on the server (which is the most trusted agent) as being the main ... and in javascript, as a validator, by you do not need to go to the server.

Note: Although I mentioned several forms of attacks that may occur, it does not mean that only validation on the server will resolve everything. Other measures are required against a Man In The Middle eg how to use SSL certificate for your domain, among others.

In a nutshell: real-time validation on the client promotes usability while server-side validation ensures data integrity and security.

In a broad sense, no. Here the scope involves not only C # and WebForms, but also other technologies.

Because the client nature can be extensively modified (through other scripts, for example), it is not safe to keep all validation on the client only. The data sent to the server can be perfectly changed without necessarily following the rules defined in the client.

Persistence operations involving referential integrity check (commonly dependencies between data entities) are usually done on the server side.

Another thing is the transactional scope of a persistence operation, which has to do with validation as well. In an asynchronous application, the only way to ensure atomicity of operations is by performing server-side processing.

The case where this can not be done is in Frameworks where there is simply no separation between client and server, which is the case of the Meteor .

A good example of this is% central%, to be consumed by several clients, such as a client API and another web .

The client Android can even do the validation, but what if web does not? Will Android be processed in the same way?

In an application I'm developing, I validate on dados ( API ), client server , and client web . At least a basic validation Android must have, to ensure that at least the data is being handled correctly at the time of processing it.

Well, it all depends on the business rule involved with validation. In the case of usability, we must execute validations on the client side, but for security, the only way to guarantee that the validation will be done is on the server side, especially in web environments.

Validation is not enough on only one side (server or client), there should be a certain combination of both.

In some respects it is best to validate on the client side, saving bandwidth and server side processing, but you should still / can validate on the server side only the "real data consistency."

There are some validations that should only be performed on the server side, but these need to be done well and be as efficient as possible.

Do not trust customer data!

Validation on the client side and inside the server serve for different things: You see, suppose the customer has some knowledge and tries to outwit the integrity of his bank. If you do the validation only on the client side it can easily circumvent your security by manipulating the DOM for example. That is, client data is not reliable, validating this data on the server increases reliability. That is:

Customer-side validation promotes better usability and agility for your user ;

Server-side validation promotes integrity and reliability of the data saved in your database and reduces the risk that possible attempts to circumvent security end up giving you a headache;