When upgrading an application from Spring Boot 2.7 to 3.2, we noticed a change in behavior for the session cookie. In 3.2, it uses the SameSite attribute provided by a CookieSameSiteSupplier bean. This is not the case in 2.7, where only setting the server.servlet.session.cookie.same-site config property influences the session cookie. I think the change was introduced with the upgrade to Jetty 10. Now, creating the session cookie goes through the SuppliedSameSiteCookieHandlerWrapper. Mitigating the effects of this change is trivial (just adapt the CookieSameSiteSupplier bean to exclude the session cookie by name), but I would like to have the documentation match the actual behavior. At the time of writing this, it says:

If you want to change the SameSite attribute on other cookies added to your HttpServletResponse, you can use a CookieSameSiteSupplier

which imho implies that it does not affect the session cookie.

Changing the documentation and maybe adding a note for a breaking change in behavior is probably the easiest fix, and even allows for more flexible configuration as seen here, for example. I haven't looked into the alternative yet, i.e. making the CookieSameSiteSupplier not affect the session cookie, but I'm willing to bring a PR either way if this is to be fixed.

Comment From: wilkinsona

Thanks, @cbrachem. From your description it sounds like the problem will be Jetty-specific and that neither Tomcat nor Undertow will behave the same way. To help us to verify if that's the case, could you please provide a minimal sample that reproduces the behaviour you have described?

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: cbrachem

@wilkinsona You are right, the problem is Jetty-specific. I've created a sample application here: https://github.com/cbrachem/samesitecookiedemo

Please note that there is a CookieSameSiteSupplier bean and also server.servlet.session.cookie.same-site is set in the application properties. The given test fails if jetty is used, but not for undertow or tomcat. (You'd need to comment out the appropriate blocks inside build.gradle.)

The reason is that JettyServletWebServerFactory.addHandlerWrapper adds a SuppliedSameSiteCookieHandlerWrapper if any CookieSameSiteSuppliers are set. If you set a breakpoint inside SuppliedSameSiteCookieHeaders.onAddSetCookieField you can observe that the originally lax session cookie is turned strict.

Comment From: mhalbritter

This works in 3.1.x, it only starts breaking in 3.2.x.