Spring Security and Error Handling

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).

Start by reproducing the two foo;bar scenarios described: an unauthenticated request rejected by the firewall and an authenticated request using basic authentication. Trace the error dispatch through the firewall, SecurityContextHolderFilter, and basic authentication entry points. Done means the relevant error-dispatch behavior is understandable to developers and the original error page remains accessible in the intended authenticated case.