Reputation: 1548
My REST API is consumed only by our own mobile apps and it also has some restricted endpoints to be used by an admin UI. It is easy to get the point of entry by observing communication of the mobile app. From there it is very easy for a malicious user to discover all possible endpoints using HATEOAS.
Even if the API is properly protected by Spring Security, there are known security leaks like https://jira.spring.io/browse/DATAREST-1144 which allow modification to read-only data.
During development, HATEOAS is useful, but I want to disable it in production to make discovery of endpoints more difficult.
Upvotes: 1
Views: 1056
Reputation: 5403
Your proposed solution implies that you intend to rely on Security through Obscurity to protect your admin functions. This is a bad idea, because a malicious actor could still guess the relevant functions that they shouldn't have access to, or simply remember what they learned by traversing your link hierarchy when you last exposed it.
You should definitely implement a robust authentication and authorization mechanism to protect your resources, and then even if a bad actor can discover the routes to those protected resources through the links structure of an unprotected resource, they won't be able to access them. Links are meant to be discovered and even if they are discovered by someone they aren't intended for, security best practices should still ensure they do no harm.
Upvotes: 2
Reputation: 14334
Rather than disabling HATEOAS (your app should be using it as a lookup for endpoints!) you should trust your security layer to do the best job it can.
Here are some considerations:
Neither of these suggestions are quick fixes but I can't recommend disabling HATEOAS. Once it is gone, you will find an issue where you need it.
Upvotes: 2