In our production system we use Spring Data Rest. We found out that it was too easy to leave a Repository method "exported" by default. We consider this as a security risk because it can be difficult to keep track of all repositories.
Therefore, we developed a new strategy to set the exported value of SDR methods to false to ensure security by default. The currently available detection strategies in SDR only allow to restrict REST repositories on class level. So when a Repository is exported, all of its methods are exported, too. Only by using RestResource(exported = false), you can prevent SDR from exporting a given method.
We created a new strategy to set the exported value of SDR methods to false. The currently available detection strategies in SDR only allow to restrict REST repositories on class level. So when a Repository is exported, all of its methods are exported, too. Only by using RestResource(exported = false), you can prevent SDR from exporting a given method.
We identified in our project, that there is a certain security risk in that case. Developers are not always aware of all the methods that are automatically exported via REST by the application. By simply adding new Repositories and just wanting a findAll()-method to be publicly available, even save and delete methods are exported by default. As most applications want to apply security especially on the write methods, an additional "pessimistic" strategy can be useful in Spring. That way you can still profit from all the benefits SDR provides, but you can be sure, that only methods you explicitly added and annotated with @RestResource are exported.
The following example shows how the exporting with the new strategy should work:
@RepositoryRestResource
interface PersonRepository extends Repository<Person, Long> {
@RestResource
Iterable findAll();
Iterable findByFirstname(@Param("firstname") String firstname);
}In that case, only the findAll() method is exported via REST. The findByFirstName and all CRUD methods like save or delete are not exported via REST by default. They have to be added explictily and annotated with @RestResource if they shall be exported via REST.
We sent our solution as pull request to Spring Data REST. We got feedback and they decide that they would integrate our new feature (https://jira.spring.io/browse/DATAREST-1176 ).