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 eclipse/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.
Comment From: natevaughan
Bump
Comment From: philwebb
@natevaughan Please don't add "bump" comments to this tracker, it causes notifications for everyone watching this repo and it won't make us get to the issue any quicker.
Comment From: 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?
Comment From: 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.
Comment From: 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
Comment From: 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.
Comment From: 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.