TL;DR:

Is there a valid reason to demand a software vendor to stop using HTTP PUT and DELETE methods in a web application and use only GET and POST? The application is security hardened, pen-tested and powered by popular security frameworks.

In other words, if I allow deletion of a record via DELETE or POST by an authorized user (checking he has access to that record, auditing, etc), what is the difference from the security standpoint?

Full question

Our customer configured their Tomcat instance with the following, according to their corporate standard:

<security-constraint> 

    <web-resource-collection> 

        <web-resource-name>restricted methods</web-resource-name> 

        <url-pattern>/*</url-pattern> 

        <http-method>CONNECT</http-method> 

        <http-method>PUT</http-method> 

        <http-method>DELETE</http-method> 

        <http-method>OPTIONS</http-method> 

        <http-method>TRACE</http-method> 

    </web-resource-collection> 

    <user-data-constraint> 

        <transport-guarantee>CONFIDENTIAL</transport-guarantee> 

    </user-data-constraint> 

    <auth-constraint /> 

</security-constraint> 

This, among the Http Header Security Filter configuration, made our application break.

Our application provides the same HTTP Header security features in Spring Security. Also, our application is RESTful, so we widely use PUT and DELETE methods for file upload. In future releases, we are also planning to use websockets (but from a search, they don't use CONNECT, which is for proxying).

Our customer said that they will have to raise a policy exception in production in order remove the offending lines from Tomcat configuration and make the application work.

As part of the security exception policy, our customer's staff is obligated to engage the vendor in "fixing the security issue" within 6 months.

This means that they will return to me asking to make the application work with enabled HTTP method filtering and HTTP Header Security filter.

I don't want to do them a favour and change all Ajax calls from RESTful patterns to GET/POST only, not even for money.

Question is, as in the TLDR, could using PUT and DELETE methods alone, regardless of the security features of the application, pose a security risk?

Edit

I work in a software factory that deploys the same product instance to a large number of customers and our cloud. We are fully using all the tools we have on board, including the REST pattern. We are planning to employ HATEOAS, WebSockets, resumable file downloads, and everything the web technology can offer us to deliver better experience. Yes, sounds like a marketing line. Anyway, security is still a concern in our products.

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:
  
  
  
  
  • You should do extra security testing to make sure no authentication or access-control bypass vulnerabilities exist via verb tampering. I recommend following the OWASP testing guide.
  
  
  • Be aware that even if your application-layer correctly enforces verb-based access controls, your webserver front-end may not. For example I believe it's possible to configure webserver front-ends to process HEAD requests without consulting the application-layer, which in some cases could be considered an information disclosure vuln, for example confirming the existence of a secret URL and telling you its content-type.
  
  
  
  

It sounds like your app is fine and your customer has an overly-zealous security policy.