#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 uses frameworks to whitelist allowed request paths and methods.

In other words, is there any difference from the security standpoint in allowing the deletion of a record via either DELETE or POST methods without changing the code and security checks in it?

#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.

The security exception policy is triggered when vendor applications do not comply with security requirement in a way that 1) fixing the issue cannot be done within the schedules and 2) no evident vulnerability is found. Exception policies require senior management approval.

However, security policy exceptions require our customer to engage the vendor within 6 months in "fixing the security issue". Within 6 months, vendor has to provide costs and deadlines to meet the security policy.

This means that they will return to me asking for a quotation 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 if possible. I would like instead to prove that their security implementation is not only incompatible, but redundant, with regards to the security implementations within the application.

If we set a precedent in doing this customer a favour with PUT and DELETE requests, we will have to face requests like "be compatible with my framework/policy/environment" from a large customer base (all banks and financial institutions). In the future, that may turn against our cost management.

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?

If proven that the sole HTTP verb does not pose a security risk, I will be able to raise a permanent exception policy and confront the IT staff with solid argumentation.

##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.