Recently, Chrome released the update that contains SameSite cookie changes to better protect against CSRF attacks. Over the course of the month of February, this was rolled out to users. You might be wondering: Will this impact the visitors to my sites running Sitecore?
Essentially, cookies are going to be “secure by default”. If an application has no declared SameSite value (like Sitecore) it will be treated as SameSite=Lax. This means those cookies are not available in third-party contexts, like an external website.
In a normal situation where a visitor is viewing a website hosted on Sitecore there will be no problems, everything will work as it is. The domain you are visiting matches the domain of the cookie and the SameSite=Lax setting will not change behavior.
If you are pulling Sitecore into another site with a different domain, for example through an IFrame, the analytics cookies are not created and Sitecore does not store any tracking information in xDB about the visitor while they are on that third-party site.
So, if you have embedded resources from Sitecore in another domain:
Sitecore uses a cookie called SC_ANALYTICS_GLOBAL_COOKIE. This cookie does not contain a SameSite attribute, and therefore any browser with the newer “secure by default” setting will treat this cookie as SameSite=Lax by default. This means that third-party sites are not allowed to use this cookie.
The team here has been testing some custom pipeline changes that you can make if you want to change the behavior of the default analytics cookie. Note that this will only work if your site runs on HTTPS because otherwise the cookie will be rejected.For example, you might want to create a processor that sets the SameSite mode to “None” in the Sitecore cookie, allowing it to run in 3rd party contexts. This needs to happen by visiting the Sitecore site! This is critical, so you want to make sure you are directing flow somehow through your Sitecore instance directly so that the cookie is created correctly, and then allowing visitors to go elsewhere to other 3rd party applications.
Here is a sample processor that the team here has been trying out:
public class AdjustAnalyticsGlobalCookieSameSite
private const string AnalyticsGlobalCookieName = "SC_ANALYTICS_GLOBAL_COOKIE";
public void Process(PipelineArgs args)
var httpResponse = HttpContext.Current?.Response;
if (httpResponse != null && httpResponse.Cookies.AllKeys.Contains(AnalyticsGlobalCookieName))
var analyticsCookie = httpResponse.Cookies.Get(AnalyticsGlobalCookieName);
analyticsCookie.SameSite = SameSiteMode.None;
analyticsCookie.Secure = true;
To get this to run when content is delivered by Sitecore, you’ll need to patch your code into the analytics pipeline as the first processor so that it runs first and sets the cookie correctly:
<sitecore role:require="Standalone or ContentDelivery or ContentManagement">
<processor type="CustomProcessor.AdjustAnalyticsGlobalCookieSameSite, CustomProcessor" patch:before="processor[@type='Sitecore.Analytics.Pipelines.EndAnalytics.CheckPreconditions, Sitecore.Analytics']"/>
What about remaining Sitecore 7.2 installations, where there are payment or single-sign-on integrations, for example, that are sensitive to SameSite? Since Sitecore 7.2 uses .NET 4.6, which is not being updated to support the SameSite changes, there's no obvious way forward. Of course, Sitecore 7.2 is itself now only in extended support, and sites should be working actively to replace it, but that's not likely to be something that can be accelerated further when there was already an end-of-year deadline in place, and upgrades are often technically very challenging. Extended support covers security issues, which this absolutely is, although it's not a vulnerability as such. What is Sitecore's approach?