Is using customer validation enough?

Question

Using Javascript validations is sufficient for efficient validation?

Example: Date validation.

• It is necessary to check also in the code?
• What are the disadvantages of only performing validations via client-side can cause?

Answer 1

I will consider that the AP speaks of the 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. These are cases that depend on information that the client does not have and that the information is not in a definitive state.

Web

I will speak on the use of the web although the conditions apply to any type of client. On the web the validation on the server is fundamental, already 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, and this need is not so important. Of course you can always take a risk in leaving the verification only in the client, but you need to understand the environment where the system will run, the culture where it will be used. For everything there are exceptions. In some cases the risk properly assessed and considered low can be compensatory. Still it is not desirable to leave all control on the client side.

Why validation should be on the server?

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

• Data coming from the customer is never reliable, they may be altered/falsified in contravention of your client’s code however much you take some precautions to make it difficult.
• There are no guarantees that you can effectively validate in all situations. You have no control over the environment where your customer is running.

You may have problems:

• data consistency
• misinformed data
• receiving malicious data
• operation of system failures
• server overload
• unforeseen failures
• things no one has predicted yet

You have to validate everything, even if you use ready-made tools framework to delegate this validation. It is common for the programmer to forget to validate some things. For example, it validates the input 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. Need to validate if the information will not open security holes in the system. But beware of tools that seem to validate well but only do something superficial. Example: ValidateRequest of ASP.NET (which is not available on the most modern .NET). It is not wrong, the error is to use it thinking it solves all your problems.

Validating only on the client

You can only validate on the client if she alone doesn’t matter to the system. It may be something that serves to facilitate the UI experience by giving additional information to the user, but that 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 need to validate on the server side. But this is rare. It is only good to be aware of this so as not to adopt a single solution blindly.

Validating only on the server

In some cases it is necessary question whether to really validate on the client side. There are cases that validating only on the server may be the best choice. It doesn’t mean that you should wait for the submission of all the data to validate everything at once. You will validate given data as it is made available by the user through a server on-demand validation service. But even doing this, when the data is definitively submitted, the validation needs to occur again (unless there is no new submission and the previously submitted data is already used, but I have doubts if this always works). The only advantage of this approach is that you avoid creating validation in a different language (uses only C# and does not need to have validation written in JS as well, facilitating the DRY, despite the fact that with the Webassembly this can change). It has the obvious disadvantage of generating more traffic and server processing.

Answer 2

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, it can send invalid data to the server

• in the case of a MITM attack, validation on the server would be more difficult

• server validations make a site less susceptible to malicious robots

In short... it is worth taking precautions against all these unknown agents, making the validation on the server (which is the most trusted agent) the main one... and in javascript, as a validation agilizer, because it does not need to go on the server.

Note: although I have mentioned several forms of attacks that may occur, it does not mean that only server validation will solve everything. Other measures are needed against a Man In The Middle for example, such as using SSL certificate for your domain, among others.

Answer 3

In a very simple summary: Real-time client validation promotes usability while server-side validation ensures data security and integrity.

Answer 4

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

Since the nature of the client can be largely modified (through other scripts, for example), it is not safe to keep all validation only in the client. 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 dependency between data entities) are usually done on the server side.

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

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

Answer 5

A good example of this, is a API central, be consumed by several customers, as a client web and another Android.

The client web can even validate, but what if the Android not do? The dados will be processed in the same way?

In an application I’m developing, I validate the API (server), on the client web and on the client Android. At least one basic validation server have to have, to ensure that at the very least the data will be treated correctly when processing them.

Answer 6

Well, it all depends on the business rule involved with validation. Regarding usability we must perform client-side validations, but for security the only way to ensure that the validation will be done is on the server-side, mainly in web environments.

Answer 7

Client-side and server-side validation serve separate purposes: You see, suppose the client has a certain knowledge and tries to circumvent the integrity of his bank. If you only validate on the client side he 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 to say:

Client side validation promotes better usability and agility for your user;

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

Answer 8

Validation is not sufficient on only one side (server or client), there must be a certain combination between the two.

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

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

Do not trust customer data!