How do the SameSite cookie changes affect Sitecore installations

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?

What is this SameSite cookie change?

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.

Does my Sitecore site still work?

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.

What if I have embedded Sitecore somewhere else?

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:

Analytics information will not be collected by Sitecore into xDB
Personalization will not work on the site where the embedding is happening.

Why is Sitecore impacted by this?

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.

How do I get Sitecore to work in third party context again?

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:

namespace CustomProcessor
{
    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:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"
    xmlns:set="http://www.sitecore.net/xmlconfig/set/"
    xmlns:role="http://www.sitecore.net/xmlconfig/role/">

    <sitecore role:require="Standalone or ContentDelivery or ContentManagement">
        <pipelines>
            <endAnalytics>
               <processor type="CustomProcessor.AdjustAnalyticsGlobalCookieSameSite, CustomProcessor" patch:before="processor[@type='Sitecore.Analytics.Pipelines.EndAnalytics.CheckPreconditions, Sitecore.Analytics']"/>
          </endAnalytics>
        </pipelines>
    </sitecore>
</configuration>

Some additional reads:

• Chromium.org: SameSite Cookie Changes in February 2020: What You Need to Know
• Chromium.org: SameSite Frequently Asked Questions (FAQ)
• Web.dev: SameSite cookies explained
• Wikipedia.org: Cross-site Request Forgery
• ChromeStatus.com: Reject insecure SameSite=None cookies