Looks to me like spring-webmvc recently refactored their cors code and broke the cors functionality in spring-data-rest.
In this commit the getHandler method was refactored to call a new method hasCorsConfigurationSource(handler) instead of CorsUtils.isCorsRequest(request).
hasCorsConfigurationSource(handler) only checks whether the handler is a CorsConfigurationSource or whether the handler mapping has a global cors configuration source set.
Since this is a new method there is no overridden implementation in RepositoryRestHandlerMapping.
As a result repository cors configurations are ignored unless there is a global cors configuration set.
I have committed a spring boot app into my github repo that demonstrates the issue.
Had a quick look at the code. If I were to submit a PR then I would probably modify the signature of hasCorsConfigurationSource(handler) to hasCorsConfigurationSource(handler, request). Before the refactor, handler mappings used the request to make cores decisions so maybe it is reasonable to reinstate this capability by having this method (in RepositoryRestHandlerMapping) return getCorsConfiguration(handler, request). But this fix span at least two repos (teams?) and also seems quite surgical. I may not (probably not) seeing the bigger picture somewhere along the line.
However, if that does seem appropriate and you want someone to do the grunt work then let me know and I will be happy to PR that
The changes in AbstractHandlerMethodMapping indeed break Spring Data REST's CORS discovery on repository interfaces. @RepositoryRestController's are not affected. As you noted, we cannot determine a repository-bound CORS config solely based on the handler but we require path/request details