Support SameSite attributes on session Cookies for Servlet-based applications

[bclozel]

This issue is about configuring the SameSite attribute in a consistent way for session cookies in Servlet-based applications (like Spring MVC).

Here's a link explaining the basics about SameSite Cookie attribute: https://web.dev/samesite-cookies-explained/

Google Chrome and other browsers are about to enforce new security policies for SameSite attributes in Cookies. See:

• Chromium timeline for SameSite updates: https://www.chromium.org/updates/same-site
• Initial announcement: https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
• Rollout is delayed: https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

As explained by Rossen here, the Servlet spec does not support this attribute yet, support is scheduled for Servlet 5.1.

Currently, Servlet containers are shipping native support, each in its own way.

Jetty provides an API on its Cookie implementation directly, this require to get access to Jetty's native Request. Developers can also set that value for Session cookies only through a session config comment (in web.xml and probably the Servlet API. As of jetty/jetty.project#4512, one can also provide a default SameSite value for all Cookies.

As explained in this comment, Tomcat provides a Cookie processor that changes the SameSite attribute for all outgoing Cookies.

Undertow has a dedicated issue for comprehensive support (scheduled for 2.1.0 release currently). A SameSiteCookieHandler will allow to configure a default SameSite value for all Cookies (or a subset using a name pattern). Note that initial support was added in UNDERTOW-1024 directly on its Cookie implementation, but it does not support all SameSite values from the spec.

See #15047 for more information, in the context of the same improvement for Spring Session.

[bclozel]

@natevaughan given that there’s no official Servlet support, the current state of things would only allow us to apply a configured SameSite attribute on all outgoing cookies (not just the session!).

Would that work for you? Could you describe your use case and elaborate on security concerns (one way or another, no support or support for all cookies).

We could also document ways to achieve that for each server implementation in our documentation. Would this be enough?

[natevaughan]

We could also document ways to achieve that for each server implementation in our documentation. Would this be enough?

I think that would be great. My initial assumption was that this was a Spring Boot issue, and that's where I started looking for solutions. Now that I understand that it's an underlying servlet container issue, I know where to look.

I think if Spring Boot can provide the breadcrumbs to point others to the appropriate servlet container configuration, then that's a good outcome.

Just a note, the top comment here could clarify that this issue is really more documentation of potential solutions. Lot of helpful resources here, but this issue looks like an explanation of the problem, not a bunch of links to possible solutions.

[sp193]

Now that we're in 2022, what's the proper way to deal with this?
I have a webapp that will be embedded within another app's iFrame. However, it fails to work in today's Chrome versions because I cannot seem to get Spring Boot 2.6.3 to set the SameSite attribute of Set-Cookie to "None".

I tried to change this value with the following attribute in application.properties:

server.servlet.session.cookie.same-site=none

However, the SameSite attribute does not appear:

Set-Cookie: JSESSIONID=6CE957767D4222B7B23D4B34B8407706; Path=/IOT; Secure; HttpOnly

[bclozel]

@sp193 if you believe you've found a bug, please create a new issue with a repro project: a minimal project that shows the issue that we can git clone/download and run.

[sp193]

Hi. I did more debugging confirmed that the SameSite attribute is actually being set, but this was being eaten up by the old version of ForgeRock OpenIG I was using. :(
After upgrading, the issue went away. Thanks for indirectly confirming that it was expected to work.