Salesforce Impact - Cookie 'SameSite' attribute, upcoming browser upgrades in 2020

Cookies are a tiny piece of the critical text, which handles a lot of things knowingly, and unknowingly, like your session/login, cart, preferences, analytics, behavior, etc. Salesforce consultants are mostly isolated from all ground-level details of Cookies etc, as it's platform's beauty to support rapid development, and provide a click-based abstraction of most complicated technical challenges. Thus, saves the consultant's time in reinventing, and investigating the same.Today, I noticed an email about an alert from Salesforce about: Google Chrome Browser Release in February 2020 Changes SameSite Cookie Behavior and Can Break Salesforce Integrations. It says:

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 80 release sets cookies as SameSite=Lax by default. Previous to the Chrome 80 release, the default is SameSite=None. Developers can still opt in to the status quo of unrestricted use by explicitly setting SameSite=None; Secure.

SameSite behavior of cookies was specifically interesting to learn and observe before any Salesforce consultant comes into a panic about their Salesforce integrations. This post covers some key Cookie terms, and details about SameSite cookie behavior and how Salesforce consultants can understand its impacts on their Salesforce solutions.

Cookie-related terminology

Let's get comfortable with some key Cookie-related terms, before moving ahead.

1. Current Site Domain: Domain visible in the Browser's address bar.

2. First-party cookie: The current site domain matches the cookie's domain.

3. Third-party cookie: Cookie's domain is different from the current site domain.

4. Top-Level Navigation: A URL click, button submit/click, etc which changes/impacts browser address bar URL.

SameSite = None vs Lax vs Strict

Let's review what is the difference in all three modes.

SameSite = None

Cookie is open for sharing with 3rd party context, across different domains, and sites. In case a webpage is without a SameSite attribute, it is currently defaulted to SameSite=None by browsers. With the upcoming change in Feb'2020, an additional "Secure" attribute is a must to avoid rejecting the cookie to browser's default.

SameSite = Strict

As per OWASP: The strict value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing contexts, even when following a regular link. For example, for a GitHub-like website, this would mean that if a logged-in user follows a link to a private GitHub project posted on a corporate discussion forum or email, GitHub will not receive the session cookie and the user will not be able to access the project. A bank website however most likely doesn't want to allow any transactional pages to be linked from external sites so the strict flag would be most appropriate here.An easier to relate example is from Netsparker:

Setting a cookie as Strict can affect browsing experience negatively. For example, if you click on a link that points to a Facebook profile page, and if Facebook.com has set its cookie as SameSite=Strict, you cannot continue navigation on Facebook (view the Facebook page) unless you log in to Facebook again. The reason for this is because Facebook`s cookie was not sent by this request.

SameSite = LAX

As per OWASP:  The default lax value provides a reasonable balance between security and usability for websites that want to maintain the user's logged-in session after the user arrives from an external link. In the above GitHub scenario, the session cookie would be allowed when following a regular link from an external website while blocking it in CSRF-prone request methods (e.g. POST). Here, CSRF-prone request methods means, only GET requests are allowed, that causes TOP LEVEL navigation to happen.As explained by Netsparker:

Resources can be loaded by iframe, img tags, and script tags. These requests can also operate as GET requests, but none of them cause TOP LEVEL navigation. Basically, they don't change the URL in your address bar. Because these GET requests do not cause a TOP LEVEL navigation, thus cookies set to Lax won't be sent with them.

The above Facebook example will work well if the user is visiting a FB link via emails, and other websites. As this causes TOP Level navigation, and the user will get the SameSite=LAX cookie, this if the session is tied to such a cookie, it will not ask for login again.

Conclusion

• This is nothing impacting urgently, it's only specific to Chrome's Feb'20 v80 update. Firefox and Edge will add this support later. You need to act promptly If your users are mainly on Chrome.

• SameSite=Strict for banking websites, and sensitive cookies, like any secrets, sessions, or anything sensitive which must stay on the original domain, and it's fine for the user's to have extra clicks/login to reach the same stage.

• SameSite=Lax for anything which is slightly more lenient cookies and could be shared when the user lands via email, other websites or social media.

• SameSite=None: Only "None", will not work in the coming months, it will be replaced by "Lax". Make sure "Secure" is added to the Cookie, and the referencing 3rd party websites are over HTTPs to share cookies.

• No SameSite added to Cookie, it will default to SameSite=Lax after Feb'20 in Chrome, and shortly after that in Firefox and Edge.

Handling SameSite on various Salesforce Clouds

• Don't rush to implement it in your production, specially if you have an e-commerce solution integrated. (It's a holiday time).

• General Customisations/Integrations: Enable chrome flags as described here and test your integrations in sandboxed mode. These chrome flags will simulate the Chrome 80+ env in your current Chrome browser.

• Handling this impact in Salesforce

  • Marketing Cloud

  • Pardot Web Tracking

References

• https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

• https://web.dev/samesite-cookies-explained/

• https://textslashplain.com/2019/09/30/same-site-cookies-by-default/

• https://github.com/GoogleChromeLabs/samesite-examples

• https://caniuse.com/?search=same-site