More strict parsing of pageable parameters [DATACMNS-1696]

Paul Vorbach opened DATACMNS-1696 and commented

During a penetration test, we found that you can enter pretty much anything to the query parameters of endpoints that take an argument of type Pageable and the value will get accepted.

For instance, if you have a @RestController listening on /myPageableResource, you can perform requests to /myPageableResource?page=0%20AND%201%3D1%20-- (for readability the URL-decoded value of the page parameter is "0 AND 1=1 --"), the request will be accepted and the default value of 0 for page will be used. The same holds true at least for the ignoreCase parameter of the sort parameters.

I'd argue that it would be better to return a 400 Bad Request instead in this case, where the value for page is obviously invalid. If users happen to enter a bad value by accident, they might not realize why they always get the first page as a result.

 Suggestions for the implementation:

The pageable parameters get parsed by the PageableHandlerMethodArgumentResolver. There also is a PageableHandlerMethodArgumentResolverCustomizer, which can be used to e.g. change parameter names or the maximum page size. Since changing the parsing behavior would be breaking, I'd suggest to allow for customization via the PageableHandlerMethodArgumentResolverCustomizer instead, but a breaking change could probably also be acceptable here.

Do you think this is a valid request? Are there other ways to customize the current behaviour that I have missed (other than re-implementing the HandlerMethodArgumentResolver and changing its behavior)?

Affects: 2.1.16 (Lovelace SR16)