Return status code 405 instead of 404 when wrong method is used
Defining an API involves creating the resources and the allowed methods for each resource. When invoking the operation (accessing the resource) with a wrong HTTP method (for example, PUT instead of GET), the API Management service returns a 404 Resource Not Found instead of a 405 Method Not Allowed. Passing an OWASP test implies to return the correct code (https://www.owasp.org/index.php/RESTSecurityCheatSheet#HTTPReturn_Code).
Is it possible to return this code with API Management right now? Will it be included in future releases
Good point, Carlos. We optimized route matching for efficiency which unfortunately prevented us from returning 405. Given sufficient support for this suggestion, we will try to address it in the future.
Chun Liu commented
@Stephen, handle the configuration error would help you do the trick. I document the details here: https://chunliu.me/2020/05/01/return-http-405-when-http-method-not-match-in-apim/
Stephen Gray commented
I thought one option would be to check in the main “All operations” incoming policy for the http method (GET,POST,PUT etc..), check the request PATH and to return a 405 but unfortunately the policy won’t get hit due to APIM cutting off the request (and responding with a 404) in the middleware (I guess)
One option, as a workaround, is to create a new operation to handle the invalid request method, in our case the GET. In APIM you need to create a duplicate operation (the only difference being the Method) and to then add a incoming simple policy to immediately return a HTTP 405 Response together with a slightly different message to distinguish that we tampered with response (but you don’t need to do this).
<set-status code="405" />
<set-body>Method Not Allowed : Please check the API documentation.</set-body>
Anurag Maheshwari commented
Is the above limitation still exists? I'm still getting 404 Resource Not Found instead of a 405 Method Not Allowed.