Try our conversational search powered by Generative AI!

Upcoming SameSite cookie changes and Episerver


There are some quite big changes in Chrome 80, and later on in Firefox/Edge(With Chromium), that affects cookies. 

Some good litterature here:

This will break quite a few flows that might not be Episerver specific, but a few things Episerver uses are also affected. For example Episerver Commerce relies on anonymous identification and the anonymous identication module does not seem to be updated to set the SameSite cookie attribute, so will potentially break in some browsers affecting carts and so on. Also it seems using the content delivery api could also be affected depending on how you use it.

I tried both the Chromium beta channel and also enabled the SameSite feature flags in current Chrome browser and there is quite a few warnings in the developer console about cookies being blocked which will affect various features in Episerver and its addons is my guess.

So my question to Episerver and the community is: what have people done to mitigate this? Have you experienced any breaking stuff in your current solutions when using the beta versions of Chrome?

Jan 06, 2020 12:56

Hi Thomas

Have you tried adding the following to Web.config? It will make all HttpCookie instances default to SameSite=Lax (or Strict) in the response.

    <httpCookies sameSite="Lax" />

If you use OWIN cookie authentication middleware, it needs to use a CookieManager that adheres to the above configuration. Like the following.

app.UseCookieAuthentication(new CookieAuthenticationOptions
    CookieManager = new SystemWebChunkingCookieManager()
Jan 16, 2020 13:35

Hi Stefan,

yes I know how to adjust various things via configs in .net 4.7.2, but there are so many gotchas, for example:

Setting SameSite=Lax will break openid connect flows which uses response type form (Azure AD for example)

Setting SameSite=None will fix openid connect flows, but will not work in safari on macos and ios, unless it is the newest version of macos and ios. So you need browser sniffing, which Microsoft and Google recommends, and others recommend double cookie strategy (Auth0).

Also Episerver Commerce relies on the anonymous identification module, which also does not handle SameSite so carts will most likely break in some scenarios. Episervers anti forgery cookie also does not set SameSite and the list goes on.

We are going with Microsofts recommendation here:

But that doesn't fix the anon cookie for example, so I sure hope Episerver have tested this. Other things could be broken, but these are the things I have discovered.

Jan 16, 2020 15:25

Did you reach out Episerver support for this case?

Jan 17, 2020 15:34

Hi Thomas

My post was about making ASP.Net and OWIN set the SameSite value in the cookies. The settings I posted adds SameSite on all cookies: .ASPXANONYMOUS, __RequestVerificationToken as well as all OWIN authentication cookies.

I haven't yet tested SameSite with OpenID or other external login flows.

Assuming that non-OWIN cookies, like the anonymous cookie and the CSRF cookies, can have same SameSite mode for all browsers, you could set a default in web.config (covering non-OWIN cookies) and use that SameSiteCookieManager (from the link you posted). This assumes that the SameSiteCookieManager is changed to sniff the user agent and change/override the SameSite mode of OWIN cookies, before calling the inner cookie manager.

Edited, Jan 20, 2020 7:44

Just want to chime in to say that Thomas's recommendation for specifying the CookieManager in both CMS and CommerceManager Startup.cs files worked for me. 👍

Aug 08, 2020 17:50
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.