-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Add ability to disable an endpoint #1882
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@SledgeHammer01 This enhancement makes sense. We'll consider adding it. |
We are in an identical situation and following a PEN test have been asked by our AppSec team to disable unused end points. We are only using the |
Hi @jgrandja, I am interested in working on this issue, and have read your comment in #1498 that we better not to have a flag setting for each configurer. How about we have a For example in
Then we can disable the endpoint by
What do you think? |
Issue spring-projectsgh-1882 Signed-off-by: Tommy Tsang <[email protected]>
…onServerConfigurer and OAuth2ClientAuthenticationConfigurer Issue spring-projectsgh-1882 Signed-off-by: Tommy Tsang <[email protected]>
This should follow the same pattern as I do not like @tommyttf's solution at all, as it's inconsistent with anything else. |
Spin off of #1454
Expected Behavior
As discussed in #1454, there is no clean way to disable the endpoints (including removing the filters, etc) we don't want. In our case, we want ONLY /oauth2/token and disable everything else including ./well-known, etc.
Current Behavior
Out of the box experience is that many endpoints are enabled for all the different flows, i.e. /authorization /.well-known, token revoke, introspect, etc.
Context
From a security perspective, our company has regular pen testing and SecOps and we get complaints about disabling unnecessary endpoints to minimize attack vectors.
If the user is configured for client credentials post for example, they can still send requests to all the other oauth endpoints and they are returning 400s if the request is malformed, letting an attacker know they are there. Also this is adding unnecessary processing since the filters are there and do checks to validate the requests.
The text was updated successfully, but these errors were encountered: