WebFirewall falsifies method not allowed responses

[reitzmichnicht]

Describe the bug
With Spring Boot 3.4.3 and Spring Security 6.4.5
Testing a not annotated HTTP method against a Spring Rest Controller is expected to return a 405 http status, but instead returns 400 in some cases.

To Reproduce
Setup a RestController endpoint in spring and include spring security with default firewall settings. Then issue a TRACE request against the endpoint. (Trace is by default blocked by the spring security firewall settings)

Expected behavior
The spring web stack internally correctly generates a 405 response in this case, but the HttpStatusRequestRejectedHandler does map all those errors to a 400 bad request. While it could be argued that this is security by hiding details, this is not the case as the Allow header from the 405 response is still part of the bad request response. Our quickfix is to patch the HttpStatusRequestRejectedHandler to not overwrite 405 responses, but I do not know if this is the desired solution.

Sample
Can be provided on request.

[rwinch]

As you correctly pointed out, the firewall is intentionally responding with a 400. For your scenario you believe that a better status code is a 405, but if a request of TRACE /missing/resource is performed, then a status of 404 is likely more appropriate. Without traversing the logic of the web application to determine if the route is valid or not, the firewall cannot know what status is best. However, the point of the firewall is to prevent the traversal of the application logic with requests that have a high likelihood of being malicious to reduce the attack surface.

That said, you have two options:

1. If you are not concerned about XST (and similar attacks) and want to support TRACE, you can instruct the firewall to allow TRACE requests.
2. If you want to return a 405, then you can create custom error handling by exposing a RequestRejectedHandler as a Bean.

Please let me know if that resolves your concern.