How do the SameSite cookie changes affect Sitecore installations?

Looking through glass lenses at the underside of a dock in water

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?

UPDATE 2020-04-08: Google has announced that they have temporarily rolled back this change and announced that it will come back at a later date in the year.

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. 

Diagram showing direct visit working, indirect visit not working

So, if you have embedded resources from Sitecore in another domain:

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


Why are Sitecore analytics 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 analytics to work in third party context again?

The team here has been testing some 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.

Make all cookies have SameSite=None

The simplest change to make is to force ALL cookies to be set to SameSite=None. If you need federated authentication or are using Identity Server, you'll need this change mentioned in the KB article for Federated Authentication:

Configure the default values of cookies in the <system.web> section of the web.config file as follows:

<httpCookies sameSite="None" requireSSL="true" />


If you want to restrict the change on cookies to only the analytics cookie, you will need a custom processor. 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=""

    <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 authentication? 

The SameSite changes also impact Federated Authentication and Identity Server. You can apply some SameSite plugins to your installation to resolve this issue on Sitecore 9.1+. The details for the changes are available on our KB site:


Some additional reads:

  • 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?

  • Is Lax value going to be defaulted when the cookie does not set the attribute same site regardless of the browser ?  i saw the chrome update on this  what about other browser update ? would be great if we have the references posted here

  • : As you mentioned, support for 7.2 in this case is not something that would be provided by Sitecore. The suggested approach is to upgrade to a supported version where you can meet your requirements.

    That being said, it should be noted that Chrome has rolled back this change temporarily to buy teams more time during the current situation. I have also updated this blog with links and information from a new KB article we have concerning Federated Authentication and Identity Server. Some of those changes may be able to help you with your Single Sign On implementation, but obviously would not have been tested for a Sitecore 7.2 scenario and are intended for Sitecore 9.1+.

  • Hey , a very good point on other browsers. Note that Chrome is coming out with this first and that Microsoft and Firefox have confirmed their intention to do the same on their own timeline. Also, note that recently Chrome rolled this back until a later time, so there is some time to get prepared now.

  • Hi Jason St-Cyr , As per the KB article for adding the SameSite attribute for Federated Authentication. Once we configure <httpCookies sameSite="None" requireSSL="true" /> the cookies SC_ANALYTICS_GLOBAL_COOKIE is cofigured to SameSite="None" but along with that __RequestVerificationToken cookie also gets configured as SameSite="None". Is it advisable to configure __RequestVerificationToken as SameSite="None" since it gets generated when we add  @Html.AntiForgeryToken() in the cshtml view. Or would it be ok if we only configure SC_ANALYTICS_GLOBAL_COOKIE as SameSite="None" through pipeline processor and then follow rest of the steps as mentioned in KB article for Federated authentication.

  • Hi , I'm not sure what the impact would be of only targeting the analytics cookie. You'd have to test to see what impact it has to your solution. If you contact support about it, my guess is that the solution in the KB article has been tested as is and that they would not have tested the scenario you are proposing.

    My suggestion would be to configure both ways and see what impacts you have to your specific application scenario in a non-production environment that is configured like production. That way, you can make an informed decision on which approach makes sense for you by balancing the negatives/positives of both approaches.