Normally, both foreground verification and background verification are required.
Because JS validation is not secure, you can completely bypass your JS validation if done intentionally.
If you are developing a commercial application, stability and security are very important, and there are security holes here.
Client-Side Validation: Just for convenience, it can provide users with quick feedback, giving the feeling of running on a desktop application, allowing users to detect the illegality of the data they fill in in a timely manner. Basically, it is implemented with script code, such as JAVASCRIPT or VBSCRIPT, without handing over this process to a remote server. If all verifications have to pass through the requesting server, the server is under too much pressure and it is not necessary.
Server-Side Validation: Necessary for building secure web applications, it ensures that all data sent by the client to the server for final processing is valid, regardless of what is entered on the client side, in order to avoid some bugs or unwanted abnormal.
For example, on a registration page, after filling in the registration information, you click the submit button, then it will prompt you to fill in an error without jumping. This process is generally very fast, and the page does not shake when returning, but if you use server-side verification, After you fill it out, you may jump to another page, return very slowly, there may be a blank period in the middle, and the page will be rewritten or shaken after returning. Client-side verification does not require dynamic language before submitting the page to the server for dynamic processing, while server-side verification actually implements verification by submitting information to the dynamic page on the server.
From this aspect, it can be known that the client-side verification is faster, the local machine verification can be achieved, and the user's waiting time can be reduced . If the user submits to the server-side verification, the user waits for a few minutes before returning to the incorrect registration prompt. Isn't it annoying for users? Therefore, client-side authentication is more friendly. But the server-side validation is more secure , because the code is invisible on the client side, and the client-side validation code can be seen clearly from the HTML page of the "source file" of the web page.
The idea that client-side validation alone is sufficient is based on several assumptions. Such as: assume that all web application users are equally honest, assume that all users will always access the web application using the browser they tested, and many other assumptions. However, such an assumption is an excellent starting point for a saboteur.
In fact, you can send any "posted" form by typing the appropriate URL into a browser window, and while such "forms" can be easily prevented from being sent by disabling GET requests for those pages, it does not prevent the user from simulating a Forms submit data to hack your system.
Take the user registration form as an example, after obtaining the registration form, the user can view its HTML source code, save it, remove the JavaScript code, save it as a local HTML file, run it locally, fill in the data, and the same The purpose of submitting unreasonable data to the server can be successfully achieved.
Summarize:
"Client-side authentication brings convenience to users. The reason for its existence is mainly for users, but it cannot guarantee security and users can easily bypass it. Therefore, for a secure data authentication scheme, server-side authentication is necessary. This requirement must be taken into account when designing the application system.