In a Spring Boot application I have created a custom ErrorController that handles all errors and decides the appropriate response, following the approach described here.

@Controller
public class CustomErrorController implements ErrorController {
    ...
    @RequestMapping("/error")
    public String handleError(
        Model model,
        HttpServletRequest request,
        Authentication authentication
    ) {
        ...

I have set the following properties to turn off the default white-label page and wire up my error handler:

server.error.whitelabel.enabled=false
server.error.path=/error

At certain times the application needs to be restricted to a small designated group of people, and at such times the error handler includes a message to that effect in its 403 (Forbidden) response.

This all worked well in Spring Boot 2.7, but after upgrading to 3.2 I am finding that 403 (Forbidden) errors appear not to be going through my handler, resulting in a default response body that lacks corporate styling and (more importantly) any accompanying explanation. Instead it seems that once the application has decided that access is denied, it attempts to access the /error resource, but then this is also denied, leading to an infinite-loop scenario that results in the default response being returned. I managed to get the application to use my error handler again by explicitly permitting access to the /error resource in my security configuration:

.requestMatchers("/error")
    .permitAll()

However this wasn’t required under Spring Boot 2.7 – I’m guessing that the framework automatically permitted access to the resource designated by server.error.path. If so, has this behaviour changed in Spring Boot 3.2?