You should never believe a customer’s information, this is the basic rule.
You can include client-side filters and validations in order to provide a better user experience, as errors will be immediate, not having to wait for server response.
But you must do the same check on the server.
There is no way to know the "request origin", forget it. CORS only affects the context of the browser, it is not the only form of communication with websites. CORS is made so that the browser, honest, do not allow connections between sites.
You can simply "swindle" using the 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
adding the headers of Origin
and Referer
, which will mislead any "source" validation. In addition, we add the User-Agent
to pretend to be a common browser. After that we send any arbitrary information, such as: nome=12345&email=xxxxxx&senha=000
, if the filter is only on customer, we completely ignore.
This breaks rule number 1 of the web: never trust your client’s data.
– Woss
What if the attacker makes an XSS on your website and requests your own domain? In an ideal case, that you close any and all security loopholes, who knows, you might even trust, but who’s going to guarantee that you closed them all? I find it a lot less work to do the validation in the backend too - and certainly a lot cheaper.
– Woss
@Andersoncarloswoss could give an answer by deepening all this?
– Costamilam
No, never validate the data only on the front. The browser itself gives you the possibility to edit a request, so its limitation in CORS is worthless.
– Tom Melo