Prevent issues with your website
This month (February 2020) Google is rolling out new requirements on the use of certain cookies in the Chrome browser. Google Chrome will now ‘block’ certain cookie functionalities, even though these can be very important to your website. Much like Chrome, most major browsers are now reviewing their cookie settings. Continue reading to find out how you can prevent suffering under these changes.
This article first elaborates on the (technical) background of the changes, and will conclude with the solution. If you are at a lack of time, just scroll down to ‘The Solution’ section. At least share this information with your web developer, in case you do not technically maintain your site yourself.
Cookies – What are they again?
Quick refresher: Cookies are small files that have been saved by your web browser, in order to remember certain important bits of information. Cookies are, whenever necessary, capable of sharing this information with more than just 1 website.
A cookie for instance saves your site preferences, like the language you’d prefer to visit the website in. Are you logging on to your favorite shopping site, in order to access your account details in an instant? Without cookies you would have to log on, on every page over and over again.
So cookies essentially save information about your web visit, in order to access that data again later. This data can be used for local use (just on your website), but could also be transferred to a session on a related website.
Cookies therefore are quite a handy solution for exchanging information between your browser and servers, without the need of massive amounts of server storage. Besides that, a cookie can be set-up to ‘automatically’ be deleted after a certain period of time. It does not have to exist any longer than necessary.
Access to a cookie
A cookie can behave differently based on the settings/parameters it was created with. The most important distinction this article discusses, is by ‘whom’ a cookie may be read and if this must be done over a safe (encrypted) connection.
You wouldn’t want certain information to fall into the wrong hands. You would for instance want to prevent a malicious website, to be able to log on to your banking website under your name with your credentials. Unfortunately all cookies are in principle always being transferred on any server request (with every HTTP header). This happens irrespective of the request being with good or evil intent.
SameSite flag: Restrict (unwanted) information exchange
Since a couple of years now it has been possible to configure ‘whom’ (which web domain) and under which circumstances a cookie can share its data, in order to regulate (unwanted) information exchange. This can be configured with the so-called ‘SameSite’ flag.
According to OWASP (owasp.org), the definition of the SameSite attribute can be stated as:
“ SameSite prevents the browser from sending the cookie along with cross-site requests. The main goal is mitigating the risk of cross-origin information leakage. It also provides some protection against cross-site request forgery attacks. Possible values for the flag are ‘Lax’ or ‘Strict’. “
For websites where cross-site access is very important (e.g. with almost all banking platforms), an even better solution should be in place. One would use a so-called CRFS token. That’s not what is being discussed in this article, but if you want to read up on it more, you can do that here: Cross-site request forgery (Wikipedia).
Example: SameSite flag
To clarify the use of the SameSite flag a bit better, a (simplified) diagram can be found below. It shows 3 websites:
- A personal website ‘https://mysite.com/’.
- A related website ‘https://knownsite.com/’ based on a TLD*.
- An unrelated website without TLD* ‘https://safesite.com.grabyourmoney/’.
*TLD: Top-level Domain – The top-level domain is the part of the domain name behind the dot (e.g. ‘.com’, ‘.nl’ or ‘.org’). This last part has to abide by certain rules in order to be a qualified domain name. Check out this Wikipedia article for more information on that.
Access to the cookie of https://mysite.com/ based on the SameSite attribute can be divided into 3 categories.
- Strict: Cookies can only share data with https://mysite.com/.
- Lax: Cookies can carry (session) data from https://mysite.com/ to https://knownsite.com/ whilst surfing from one to the other.
- None (or cookies without the SameSite attribute): can share (session) data with any website, regardless of its origin. E.g. between ‘https://mysite.com/’ and ‘https://safesite.com.grabyourmoney/’.
Since February 2020, Google Chrome has put restraints on this last variant.
What has changed?
From Chrome version 80 on, all cookies that do not explicitly carry the SameSite:None and Secure (https) flags, are being converted to SameSite:Lax cookies.
This means that cookies that are aimed at information exchange over multiple domains, but not have been labeled as such, will no longer be able to share this information between the domains in the way it could before.
Google Chrome has warned users of the browser of this upcoming change since version 76, by displaying the following message in the console of the browser.
Source: Chrome Platform Status
This update has primarily been regarded as a security measure. Besides that, it (positively) boosts the cookie user’s awareness, about the properties of cookies. Quite a sum of information is often unintentionally shared over the internet.
The Solution
In the case your website uses cookies, where information exchange between different domains is vital, it is important that these cookies will be updated. Make sure these cookies explicitly carry the SameSite:None and Secure flags. In that way a cookie can share its data ‘legitimately’ and over a secure connection with other domains. A developer can often provide you with an answer about whether this is relevant for your website.
Not all cookies that are available from your website, are being created under the full supervision of your developer. Tracking pixels and tracking scripts are often managed by an external party like Google, Bing, Facebook, LinkedIn, Indeed, Awin, etc.. In those cases you’ll have to rely on their developers to update the relevant cookies in use by their tools.
Have you embedded any – God forbid – iframes from another site on your website? Then too you’ll have to rely on the developer for that specific domain to process the changes.
Most developers that use cookies, are already informed about these changes, but it never hurts to ask! Better to be safe than sorry!
Lastly
If your cookies do not require any cross-site features, you don’t necessarily have to worry right now. Access is being restricted for cookies that share information outside of your website, but it does not impact any cookies that live within your website. Double check this with your developer.
This moment is a nice opportunity though to have a conversation about cookies. Maybe a couple of cookies could be restricted further to ‘Strict’ cookies, in order to make the chance of data leakage slimmer.
How does your website actually handle cookies? Does it comply with the GDPR?
Maybe a chunk of cookies could be converted to localStorage (a lot quicker and safer).
If you have any more questions about this, then we at Maxlead will be ready to assist you.
More information?
Are you interested in more technical details about cookies and/or localStorage, then go ahead and use some of the following links to explore and read up on it some more.
Cookies vs localStorage (Medium.com)
Developer’s guide on HTTP cookies (Mozilla.org)
Developer’s guide on localStorage (Mozilla.org)
SameSite cookies explained (web.dev)
Cross-site Request Forgery (Wikipedia)
