You should never believe in customer information, this is the basic rule.
You can include filters and validations on the client side to provide a better user experience, since the errors will be immediate, not having to wait for the server to respond.
But you must do the same verification on the server.
There is no way to know the "requisition source", forget it. CORS only affects the browser context, it is not the only way to communicate with websites. CORS is meant for the browser , honestly, it does not allow cross-site connections.
You can simply "circumvent" it by using cURL , for example:
curl ^
-H "Origin: seusite.com" ^
-H "Referer: https://seusite.com" ^
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36 OPR/54.0.2952.54" ^
-d "nome=12345&email=xxxxxx&senha=000" ^
-X POST ^
https://seusite.com/registrar
Note that we are pretending to be in seusite.com by adding the headers of Origin and Referer , which will fool any "source" validation. Also, we added User-Agent to pretend to be an ordinary browser. After that we send any arbitrary information, such as: nome=12345&email=xxxxxx&senha=000 , if the filter is only on the client, we completely ignore it.
No ! From an attacker's point of view, there is no "secure validation on the front end", it will simply be ignored.
As much as you limit the source of the request (CORS), it is extremely simple to edit the content of a request using tools like BurpSuite or even through the browser itself. That is, you can send a valid request containing a malicious payload.