This post is brought to you by Luca Miglioli, an Information System Analyst that works at WebResults (Engineering group) in the Solution Team, an highly innovative team devoted to Salesforce products evangelization.
Some months ago, Google announced a secure-by-default model for cookies, enabled by a new cookie classification system. Changes concern in particular to the SameSite attribute: on a cookie, this attribute controls its cross-domain site behavior, that is if no SameSite attribute is specified, the Chrome 80 release sets cookies as SameSite=Lax by default while previous to the Chrome 80 release (the current one), the default is SameSite=None.
Ok, but what does it mean?
To safeguard more websites and their users, the new secure-by-default model assumes all cookies should be protected from external access unless otherwise specified: this is important in a cross-site scenario, where websites typically integrate external services for advertising, content recommendations, third party widgets, social embeds, etc. and external services may store cookies in your browser and subsequently access those file.
These changes are being made in Chrome, but it’s likely other browsers will follow soon: Mozilla and Microsoft have also indicated intent to implement these kind of changes in Firefox and Edge, on their own timelines. While the Chrome changes are still a few months away, it’s important that developers who manage cookies assess their readiness as soon as possible: that’s why Salesforce rapidly notifies its customers and partners with an annoucement (contained in the latest release notes, Spring ’20).
Especially, the announcement explains that:
- “Cookies don’t work for non-secure (HTTP) browser access. Use HTTPS instead.”
Check the URL of your website, if it starts withhttp://and nothttps://then you’ll need to get some form of SSL certificate. It’s probably worthwhile checking all of the links to your pages to make sure they are directing the thehttps://version of the page. For example, make sure you are using the HTTPS links if you are embedding Pardot forms on your websites: this was not enabled for our organisation by default, so it’s likely that your organisation may need to do this. - “Some custom integrations that rely on cookies no longer work in Google Chrome. This change particularly affects but is not limited to custom single sign-on, and integrations using iframes.”
1st, 2nd and 3rd party integrations might be seariously impacted. Salesforce recommends to test any custom Salesforce integrations that rely on cookies owned and set by your integration. For example, an application not working as expected could be Marketing Cloud’s Journey Builder not rendering in the browser or Cloud Pages/Landing Pages/Microsites returning blank pages. If you determine that your account is affected by theSameSitecookie change, you need to investigate your implementation code to ensure cookies are being utilized appropriately.
Ok, this looks a little bit scary, but don’t worry!
First, developers and admins can already test the new Chrome’s cookie behavior on the sites or cookies they manage, simply going to chrome://flags in Chrome (type that in the URL bar) and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments.
Second, developers can still opt in to the status quo of unrestricted use by explicitly setting SameSite=None; Secure: only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections.
Third, If you manage cookies that are only accessed in a same-site context (same-site cookies) there is no required action on your part; Chrome will automatically prevent those cookies from being accessed by external entities, even if the SameSite attribute is missing or no value is set.
That’s all! You can still find more detailed info here:
Leave a Reply