Skip to content
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

Spring Security and Error Handling #16554

Open
rwinch opened this issue Feb 7, 2025 · 0 comments
Open

Spring Security and Error Handling #16554

rwinch opened this issue Feb 7, 2025 · 0 comments
Labels
in: web An issue in web modules (web, webmvc) type: bug A general bug
Milestone

Comments

@rwinch
Copy link
Member

rwinch commented Feb 7, 2025

Spring Security requires authorization for every request and every dispatch type by default. This is by design, but it complicates developer's lives. Authorization for error handling does not behave correctly in all scenarios.

With Spring Boot 3.4.2, a request of http '/foo;bar/' will cause the firewall to reject the request. After the request is rejected, it is handled by error dispatcher. Unless explicitly allowed, Spring Security will deny access to the error dispatch and the original error will not be displayed. This is all expected, but it makes it difficult for developers to figure out. We should ensure that we perform logging to help the developer figure out what is happening.

Another issue is that even if the request is authenticated http ':8080/foo;bar/' -a user:password and that users should be authorized, it does not grant access to the error page. The problem here is likely two fold. The first is that the SecurityContextHolderFilter has a new attribute that disables it for additional dispatch types. This means that if it was invoked on the request, in the error dispatch it won't be invoked again. The other issue is that basic authentication will never be invoked on error dispatch even if basic authentication was not invoked in the request dispatch. Since the firewall rejects the request before basic authentication happens, it cannot authenticate the request in the request dispatch. Likely for this scenario, basic authentication should happen on the error dispatch (we do not want to process any of the request dispatch since the firewall rejected it and doing anything with that request could lead to security bypasses).

@rwinch rwinch added status: waiting-for-triage An issue we've not yet triaged type: bug A general bug labels Feb 7, 2025
@rwinch rwinch added this to the 6.4.x milestone Feb 7, 2025
@rwinch rwinch added in: web An issue in web modules (web, webmvc) and removed status: waiting-for-triage An issue we've not yet triaged labels Feb 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web An issue in web modules (web, webmvc) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

1 participant