![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(80, 26%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EWM%3C/text%3E%3C/svg%3E)
Hello. I noticed a very similar question posted on StackOverflow earlier; perhaps that was also from you? In any case, I wanted to share some insights here as well.
To my knowledge, there is no official update notes regarding this specific change. However, Chromium (by default) strictly enforces that any cross-site cookie set with SameSite=None must also include the Secure attribute and be transmitted only over HTTPS. If any part of your workflow uses HTTP, the cookie will not function as expected.
As for why this worked previously, older versions of the browser may have permitted this behavior for legacy reasons, but with version 139, this requirement is now strictly enforced.
Potential workarounds:
- Using a browser flag to temporarily disable enforcement (note that this affects only the local browser, not server-wide).
- If you manage a reverse proxy (such as NGINX or Apache), you can rewrite the
Set-Cookieheaders at the edge to inject theSecureattribute andSameSite=Noneas needed.
Ultimately, the correct solution is to ensure all SAML or session cookies are set with SameSite=None; Secure and that your application is served exclusively over HTTPS. Browsers will block Secure cookies over HTTP without exception.
Delaying or downgrading browser updates is also an option, but I would not advise this since it may introduce additional risks.