SOAP has more bureaucracy than REST.
Basically the difference is that in SOAP, all data types have to be pre-defined in the interface contract - so the SOAP layer itself will already issue an error if it is sent a list where there should be a string (if SOAP has list).
In REST, payload can be any JSON - and eventually a check has to be done in the application itself for some of the data arriving in JSON, otherwise it will malfunction .
As a concrete example, this happened in a project where I was: the front end sent a list, where in the backend we expected a string, and this caused a mistake in the view.
But realize that if the project was being done with proper testing and documentation this would not have happened - and also that this particular error did not present any security danger.
In general REST frameworks allow you to specify field validation - this is just not required. With the specified fields not the difference in security or reliability of the application.
On the other hand, the weight of the specs of each view, and the redundant data in each payload SOAP, make it a very bad protocol to work on almost any issue. There are many other ways to validate data in addition to replicating the payload specification everywhere using XML.