Problems with new SameSite cookie changes
By Kripa K— “An Inquisitive learner”
We are aware of Google’s launch of the SameSite updates. There were some explicit changes to the SameSite attribute to send the cookie to the third-party context. This change in turn affected lower browser versions which will be discussed in detail in this blog. Before we dive deep into the issue, let’s have a basic understanding of the SameSite attribute in cookies and its old behaviour.
The SameSite attribute in cookies allows you to declare whether your cookie should be restricted to first-party or same-site context.
SameSite attribute provides three different ways to control its behaviour:
If the SameSite attribute is set as Strict, the cookie will only be sent in a first-party context which means cookies that match the domain of the current site are the ones displayed in the browser’s address bar.
If the SameSite attribute is set as lax, cookies are not sent on normal cross-site subrequests (for example to load images or frames into a third-party site) but are sent when a user is navigating to the origin site (i.e., when following a link).
3) No Value specified:
When the SameSite attribute is not specified with any value, it means that the cookie can be sent in both contexts (First and third-party context).
Google rolled out SameSite changes on 14th July 2020, along with the release of Chrome 84. It makes the user set the SameSite attribute explicitly if it is to be accessed by a third-party context. This update will diminish the chances of accidentally introducing CSRF vulnerabilities online and improve security against CSRF attacks. Hence the SameSite updates will protect user privacy and provide a more open and transparent experience.
This in turn made developers analyse the use case and explicitly set the SameSite attribute as none if cookies are to be sent to the third-party context.
The rollout of SameSite attribute changes affected older browser versions since they are unaware of none as an attribute value. Hence these browser versions will reject a cookie (the cookie is not even set) with the SameSite attribute set as none.
The double cookie approach doesn’t seem to be ideal since two versions of the same cookie are maintained everywhere. Also, there is a limit on the cookie storage in the browser. Hence we have decided to go with the user agent sniffing approach which will have the functionality to detect browser versions. We can set the SameSite attribute to none if the version is compatible else no value should be set.https://gist.github.com/kripz97/b545a2c3bfc163eb4979a727d6cc5c58
This method covers browsers that we use frequently. This will mostly reduce the browser incompatibility issues we face with SameSite attribute changes.
We at CaratLane are solving some of the most intriguing challenges to make our mark in the relatively uncharted omnichannel jewellery industry. If you are interested in tackling such obstacles, feel free to drop your updated resume/CV to email@example.com