Why should someone block all methods other than GET and POST in a RESTful application?
I suspect this is a case of someone zealously applying "best practices" that they don't understand.
HTTP Verb Tampering Attack
The reason this best practice exists is because of the HTTP Verb Tampering Attack. From this article:
Many Web server authentication mechanisms use verb-based authentication and access controls. For example, an administrator can configure a Web server to allow unrestricted access to a Web page using HTTP GET requests, but restrict POSTs to administrators only. However, many implementations of verb-based security mechanisms enforce the security rules in an unsecure manner, allowing access to restricted resources by using alternative HTTP methods (such as HEAD) or even arbitrary character strings.
So someone decided that because some apps are badly-written, all apps should be banned from accepting HTTP verbs other than GET or POST, because ... you know ... mumble mumble SECURITY!!
My opinion (possibly incomplete / incorrect, please post comments) :
- Pure HTML / CSS / js content should be restricted to GET and POST because these are the only verbs allowed in the HTML spec.
- APIs (AJAX, REST) should be allowed to use any verb from the HTTP spec, that said:
- Be aware that even if your application-layer correctly enforces verb-based access controls, your webserver front-end may not, so you owe it to your customers to do some security testing and make sure your app enforces proper authentication and access controls on all verbs that you support. I recommend following the OWASP testing guide.
It sounds like your app is fine and your customer has an overly-zealous security policy.
As an aside, HEAD is an interesting example; some security scanners seem to complain if your app responds to HEAD requests, because some apps will return valid headers without invoking the proper auth checks. However, most properly designed apps will process a full GET and then only return the headers, including the correct content-length:. So for apps using modern frameworks, there is probably no way to bypass auth logic on your GET controller. Do some quick tests though!
(Thanks @usr-local-ΕΨΗΕΛΩΝ for pointing this out in comments. See this Stack Overflow post for detail on how Spring MVC handles this.)