Is using validation via client enough?
Is using JavaScript validations enough for efficient validation?
Example : date validation.
- is it necessary to check also in the code?
- What disadvantages of only performing validations via client-side can cause?
8 answers
I will consider that you speak of validations that could be done exclusively on the client side. There are validations that are inherently impossible to do without server help. These are cases that depend on information that the customer does not have and or that the information is not in a definitive state.
Web
I will talk about the use of the web although the conditions apply to any type of client. On the web validation on the server is fundamental, 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 that important. Of course you can always have a risk to leave the check only on 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 compensating. Still it is not desirable that it leave all control on the client side.
Why should validation be on the server?
The main reasons have already been said in the other answers, I will summarize:
- the data that comes from the customer is never reliable, it can be changed/falsified by default of your customer code no matter how much you take some precautions to make it difficult.
- there are no guarantees that you will be able to validate effectively in all situations. you have no control of environment where your client is running .
You may have problems with:
- data consistency
- poorly formed Data
- receiving malicious data
- exploiting system failures
- server overhead
- unplanned failures
- things no one has predicted yet
You have to validate everything , even if you use ready-made tools from the framework to delegate that validation. It is common for the programmer to forget to validate some things. For example, it validates the input date, but forgets about what is not obvious that might be wrong in some specific situation. He doesn't think like the hacker/cracker who will try to defraud his 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. she is not wrong, the mistake is to use it thinking that it solves all your problems.
Validating only on client
You can do a validation only on the client if it alone does not matter to the system. It can be something that serves to facilitate the UX 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 others 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 to question whether it should really validate on the client side . There are cases that validating only on the server may be the best choice. It does not mean that you should wait for the submission of all the data to validate everything at once. You go validating data by data as they go being made available by the user through an on-demand server validation service. But even doing this, when the data is submitted definitively, the validation needs to occur again (unless there is no new submission and the previously sent data is already used, but I have doubts if this always works). The only advantage of this approach is that you avoid creating the validation in a different language (it only uses C# and does not have to have the validation written in JS as well, facilitating the DRY , although with the WebAssembly this can change). It has the obvious disadvantage of generating more traffic and processing on the server.
Validating data being sent by the user in javascript alone is not enough because of:
-
If the user deactivates javascript, you may end up with invalid data on the server
-
If the user is malicious, they can send invalid data to the server
-
In the case of a MITM attack, validation on the server would be an additional difficulty
-
Server validations make a website less susceptible to robots malicious
In short... it is worth guarding against all these unknown agents, making validation on the server (which is the most trusted agent) as the main one... and in javascript, as being a validation expediter, because it does not need to go on the server.
Note: although I mentioned several forms of attacks that can occur, it does not mean that only validation on the server will solve everything. Other measures are needed against a Man in the Middle for example, how to use SSL certificate for your domain, among others.
In a very simple summary: real-time validation on the client promotes usability while validation on the server side ensures data security and integrity.
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 extensively modified (via 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 checking (aka dependency between data entities) are typically 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 cannot be done is in Frameworks where there is simply no separation between client and server, which is the case of Meteor .
A good example of this is a central API, being consumed by several clients, such as a client web and another Android.
Client web can even do validation, but what if Android doesn't? Will dados be processed in the same way?
In an application I am developing, I do validation in the API (server), in client web and client Android. At least one basic validation server has to have, to ensure that at the very least the data will be handled correctly time to process them.
Well, it all depends on the business rule involved with validation. When it comes to usability we must perform validations on the client side, but for security the only way to ensure 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 must be a certain combination between both.
In some respects the best is to validate on the client side, saving bandwidth and server-side processing, but still you should/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 must be well done and be the as efficient as possible.
Don't trust customer data!
Validation on the client side and inside the server serve for distinct things: Take a look, suppose the customer has certain knowledge and try to circumvent the integrity of your 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 unreliable, validating this data on the server increases reliability. That is:
Client-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 will end up giving you a headache;