Improve documentation on what changed in the default behaviour in version 6 vs 5.7

[asaikali]

I am going through an upgrade of a Spring Boot 2.6 to Boot 3.0 application. I found the documentation at https://docs.spring.io/spring-security/reference/5.8/migration/servlet/exploits.html to be incomplete. I have had a to spend many hours on trial and error different setting combinations to try and get my app to work, however, I still have one failing test case where on CSRF token is not getting generated when it was generated in 5.7.

I am looking for the migration docs to explain what the impact of the changes in CSRF defaults from both the client perspective and the server side spring perspective.

Ideally the CSRF docs:

• Review of the csrf behaviour in 5.7 and earlier, along with how single page and server side rendered apps typically dealt with it.
• How the CSRF behaviour changed in 5.8 and 6.0, and what the client needs to do to be compatible with the 5.8 / 6.0 behaviour (this is currently missing)
• Rational for why the changes were made in version 6, what benefits do I get in the app if I refactor the app to be compatible with spring security 6 defaults.
• How to configure the CSRF behaviour to be same as 5.7 in 6.0 if that is possible. The current docs at https://docs.spring.io/spring-security/reference/5.8/migration/servlet/exploits.html is only focused on what changed in the configuration code.

So far in my efforts to upgrade to Boot 3 the spring security changes in default behaviour have been the most problematic as I find myself having to trail and error configuration settings as opposed to being 100% clear on what I am changing and why I am changing it.

[sjohnr]

Hi @asaikali, thanks for reading through the migration guide and giving feedback!

I understand you're looking for more explanation on what changed between 5.7 and 6.0 so that your migration effort is clearer and more informed (and of course successful).

To better understand what improvements to make, I'd like to learn more about what's not working for you when you follow the existing configuration examples in the exploits page of the migration guide. For example, one issue which impacts SPA clients (as discussed in this comment) is that login success no longer generates a new csrf token. This scenario is not currently mentioned in the migration guide.

How the CSRF behaviour changed in 5.8 and 6.0, and what the client needs to do to be compatible with the 5.8 / 6.0 behaviour (this is currently missing)

The provided solution for I am using AngularJS or another Javascript framework and other existing examples on that page attempt to answer this, by demonstrating how to roll back to 5.8 defaults and require no changes on the client. Perhaps the login success scenario I mentioned above is all that's missing in this case?

How to configure the CSRF behaviour to be same as 5.7 in 6.0 if that is possible.

While there are many preparatory code changes between 5.7 and 5.8, there should (in theory) be no behavior changes between those two versions. All behavior changes should be isolated to changing defaults in 6.0. The migration guide attempts to demonstrate explicitly configuring the application for 5.8 defaults, allowing a seamless upgrade to 6.0. If there's a behavior change between 5.7 and 5.8, it may be a bug and worth investigating.

[petenattress]

Hi @sjohnr, I have encountered a CSRF-related regression in a Spring Boot 2.7 (with Spring Security 5.8) to Spring Boot 3.0 upgrade. We had some server-side rendered Freemarker templates which were relying on accessing a template variable called _csrf in order to put the token in a form input. This was relying on the _csrf request attribute being exposed to the template. As of this Spring framework change, request attributes are no longer exposed by default, so our templates failed to render.

I appreciate this isn't really a Spring Security issue as it relates to the templating behaviour in Spring MVC. However it does "look" like a Security related issue because the effect is very similar to CSRF protection not being applied (ie it appears as if there is no CSRF token on the request), so this was the first place I looked to try to work out what was going on. It took quite a bit of digging to identify the actual problem. I'm not sure how many people will be affected by this as it could be that our use is an edge case, but it might save someone some time if it's mentioned in the Security migration guide.

For anyone else who encounters this, my workaround was to set spring.freemarker.expose-request-attributes=true in application.properties.

[sjohnr]

Thanks for the tip @petenattress! I was definitely not aware of that. I could be wrong, but I would say freemarker (and possibly most Framework-specific issues) is a bit out of scope for the Spring Security migration guide. That might be something the Spring Framework team would want to know about, or perhaps it's relevant in the Spring Boot upgrade doc. But we'll definitely keep it in mind.

[ardetrick]

@petenattress I've also seen seen this issue as well and had also just discovered the workaround you mentioned, although it doesn't seem like the right fix.

If it is of interest to you @sjohnr I've put together this basic app that demonstrates the problem, although it sounds like i'd be better of sending this over to the springboot folks... https://github.com/ardetrick/springboot3-freemarker-csrf-issue