Loading

Google Chrome Browser Release 84 Changes SameSite Cookie Behavior and Can Break Salesforce Integrations

Publish Date: Oct 13, 2022
Description
Chrome is changing the default cross-domain (SameSite) behavior of cookies coinciding with the stable release of Chrome 84 on July 14, 2020, with enforcement enabled for Chrome 80+. The SameSite changes started in February 2020 with the Chrome 80 release, but Google temporarily rolled back the SameSite changes until the summer of 2020. The SameSite changes enhance security and privacy, but require customers and partners to test custom Salesforce integrations that rely on cookies.

The SameSite attribute on a cookie controls its cross-domain behavior. This Chrome Platform Status explains the intent of the SameSite attribute.
“SameSite is a reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks, but developers currently need to opt in to its protections by specifying a SameSite attribute. In other words, developers are vulnerable to CSRF attacks by default. This change would allow developers to be protected by default, while allowing sites that require state in cross-site requests to opt in to the status quo’s less-secure model.”

If no SameSite attribute is specified, the Chrome 84 release sets cookies as SameSite=Lax by default. Up until the Chrome 84 release, the default is SameSite=None. After the Chrome 84 release, developers can still opt in to the status quo of unrestricted use by explicitly setting SameSite=None; Secure.

For more information, see this Chromium blog post.


When Will the Chrome SameSite Changes Go Live?

Google's SameSite Updates page indicates that the SameSite changes will coincide with the stable release of Chrome 84 on July 14, 2020, with enforcement enabled for Chrome 80+.

Originally, Google began rolling out the changes to Chrome 80 Stable for an initial limited population starting the week of February 17, 2020. Google temporarily rolled back the SameSite changes until the summer of 2020 because of the extraordinary global circumstances due to COVID-19.

Google stages the stable rollout of Chrome and individual capabilities over time so that any issues can be detected early and addressed before they reach all users. 

Salesforce is ready for the SameSite changes whenever Google rolls them out. If you made changes and tested in your org to prepare for Google's initial SameSite rollout in February 2020, you're ready too and there's nothing more for you to do.  If you haven't yet prepared your org for this change, please review the entirety of this article for additional information. 
    Resolution

    What Does This Mean for Me?

    These SameSite changes by Google Chrome may require you to make changes in your org.

    1. Cookies won't work for non-secure (HTTP) browser access, including any community, portal, site, or Outlook or Gmail integration in your org. Use HTTPS instead.
    2. Any custom integrations that rely on cookies might no longer work in Google Chrome. This change particularly affects but is not limited to cross-domain communication, and integrations using iframes.


    What Do I Need to Do?

    1. Use HTTPS instead of HTTP
    To require HTTPS access in your org, ensure that the following Session Settings in Setup are enabled. These settings are enabled by default but you should verify that HTTPS is required in your org.

    From Setup, enter Session Settings in the Quick Find box, then select Session Settings.

        Require secure connections (HTTPS)
    Determines whether HTTPS is required to log in to or access Salesforce.
    In Spring ’20, we added the Require Secure HTTPS Connections critical update that requires HTTPS connections to access Salesforce. 
        Require secure connections (HTTPS) for all third-party domains
    Determines whether HTTPS is required for connecting to third-party domains.

    If either of these settings is disabled, Salesforce may not be fully functional for Chrome users after the Chrome 80 release.

    To require HTTPS access in communities, portals, or sites:
    a. From Setup, enter Sites in the Quick Find box, then select Sites.
    b. Click the site you want to edit, and ensure that the Require Secure Connections (HTTPS) checkbox is selected.

    To check whether your Salesforce Classic Canvas connected app works with HTTPS:
    a. In Salesforce Classic, from Setup, enter Canvas App Previewer in the Quick Find box, then select Canvas App Previewer.
    b. Click the app that you want to check. If the app loads, it means that the URLs are already set to use HTTPS. If the app doesn’t load in the previewer, update the Canvas App URL and Callback URL to use HTTPS.

    To update your Canvas connected app to HTTPS:
    a. In Salesforce Classic, from Setup, enter Create, and then click Apps.
    b. Select the Canvas connected app that you want to update.
    c. In the Canvas App URL field, update the URL to use HTTPS.
    d. In the Callback URL field, update the URL to use HTTPS.
    e. Click Save.
    f. Go back to the Canvas App Previewer and check that the app opens as expected.
    Note: The first time that you navigate to the HTTPS URL, close and reopen tabs and clear your browser history.

    Upgrade the LiveMessage Managed Package
    Similar to other features, LiveMessage (Classic) requires that the Require Secure Connections (HTTPS) and Require secure connections (HTTPS) for all third-party domains Session Settings in Setup are enabled in your org.

    The Chrome 80 release is supported on version 4.46 or later of the managed package. If your org has an older version installed, upgrade to the latest version here.

    2. Test custom Salesforce integrations that rely on cookies owned and set by your integration
    Before the Chrome 84 release, test any custom Salesforce integrations that rely on cookies owned and set by your integration. Test in a sandbox. If you find any regressions, update the SameSite attribute on cookies used for cross-domain communication to explicitly set SameSite=None; Secure. If you set a cookie in Apex, use the new SameSite attribute of the Cookie() constructor method.

    This Chromium blog post explains how to test the effect of the new Chrome behavior on your site or cookies before Chrome rolls out the SameSite changes. Navigate to chrome://flags and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. The fixes in Spring '20 apply to Chrome 78 and later.

    Note: While you're testing your cookies, consider what's the most secure SameSite value that works for each cookie. If a cookie is intended to be accessed only in a first-party context, you can apply SameSite=Lax or SameSite=Strict to prevent external access. Explicitly setting SameSite=Lax means that you're not relying on default browser behavior.

    Only Chrome 80+ sets SameSite=Lax by default. If you encounter an issue with an integration after the Chrome 80 release, you can temporarily use an unaffected browser, the mobile app, or an older version of Chrome while you implement a fix.


    What Does This Mean for Sales and Service in Lightning Experience and Salesforce Classic?

    We support the ongoing effort to improve privacy and security across the web. We updated the SameSite attribute on cookies set by Salesforce. The fixes were made in Spring '20 and apply to Chrome 78 and later.

    We recommend that you test in a sandbox with the latest version of Chrome. We will update this article when any new information emerges.


    What Does This Mean for B2C Commerce?

    See the B2C Commerce documentation.
     

    What Does This Mean for B2B Commerce?

    See this knowledge article for B2B Commerce.
     

    What Does This Mean for Marketing Cloud?

    See this knowledge article for Marketing Cloud.
     

    What Does This Mean for Pardot Web Tracking?

    See this knowledge article for Pardot.
     

    What Does This Mean for Tableau?

    See the Tableau knowledge base.
     

    Resources

    Knowledge Article Number

    000381201

     
    Loading
    Salesforce Help | Article