It isn't obvious when reading the Boot 2.x Migration Guide that one consequence of this:
The security auto-configuration no longer exposes options and uses Spring Security defaults as much as possible.
Is that, where /error was once public, it is now secured.
The Spring Boot Security 2.0 page does help by saying:
When Spring Security is on the classpath, the auto-configuration secures all endpoints by default.
But, it isn't clear to users who are migrating that this includes /error.
This has caused some confusion and heartburn for users that could be somewhat alleviated by calling it out.
Looks like there is already some of this in the guide:
One noticeable side effect of that is the use of Spring Security鈥檚 content negotiation for authorization (form login).
It may be valuable to add to the guide a bit of the rationale behind the change. Some users mistakenly believe that when they are proactively securing /error, that it is an icky workaround instead of the desired practice.
Here is some rationale that we could draw from:
/error wasn't included in this. Spring Boot 2.0 is now secure by default, too, in that all endpoints, including /error now respect the Spring Security default./error it was the case that Spring Security wasn't invoked at all, meaning that things like secure headers, https redirects, and the like weren't consulted as part of the response.I think that the nod to simpification already in the docs is a good one, too.
NOTE: It is probably obvious, but in addition to /error I think it would be beneficial to list other endpoints impacted too.
I've added a note here about error and static resources.
Could we add an example of how to do that? We might provide a way to ignore as was done in Boot 1.x but first propose they use permitAll (which is better because it allows access but enables other security features).
I added a link in that section to the reference docs which has an example.
Most helpful comment
I've added a note here about error and static resources.