Checking for unauthorized cookies has been a central point in every website audit. In this article, we will highlight the steps that will help you to check a website for this:
- Clean the browser history and let the consent tool (if there is one) appear.
- Record cookies that were set without consent.
- Identify the source and purpose of these cookies.
Dealing with consent management platforms
Consent tools have established themselves as the means of choice for obtaining consent on websites – and for giving website operators the good feeling that they are doing everything right when it comes to data protection. In fact, many websites still allow cookies through despite such tools, so it is worth taking a closer look.
Consent tools are available in very different price ranges and functionalities – some are simple open source scripts that are installed on the web server, while at the upper end of the price scale there are product suites, such as those from Usercentrics or OneTrust, which themselves run as complex external services on their own web servers. However, they all have the following simple basic principles in common:
- If a user has given consent, status information is saved in the browser (as a cookie or entry in the local storage). If you delete this information, you will appear as a user who has not yet given consent and the consent tool will be displayed again.
- Consent tools do not block cookies, but the services that set cookies. Therefore, consent tools use different mechanisms to load JavaScript tags (which represent external services) only after the user has given consent.
- The website operator can configure which scripts (and therefore cookies) are considered so essential that they are loaded immediately when the page is opened and which require consent in the consent tool.
Reset the history
Before you check a website for cookies, you should make sure that there are no old cookies that could falsify the result. The cookies in the browser may have a long lifespan and could therefore originate from a previous test – or in the case of third-party cookies even from the test of a completely different website!
In addition, a consent tool is initially no longer visible after it is closed – and even if you manage to open it again, it has often saved data, so it is better to delete the history for a new test for the sake of comparability. You can do this by specifically deleting cookies and data in the web memory:
- First open the website you want to examine and right-click in the content area. Select “Examine” to open the developer tools and then the app tab:
- Open the menu item “Local storage” and right-click on each sub-entry and then select “Delete” in the context menu.
- Repeat this for “Session storage” and “Cookies”.
What is “local storage”?
Local storage is a somewhat newer technology than cookies. It enables all common browsers to store and read data in the browser using JavaScript. The most important differences to cookies are
- Data from the local storage is not transferred to the server without being asked (even if this is of course possible with a request triggered by JavaScript).
- Data is retained until it is actively deleted.
- There are fewer restrictions on the amount of data – 5 million characters per domain, compared to approx. 4000 characters per cookie.
Local storage is also covered by the EU ePrivacy directive. You can view the written data in the app tab of the developer tools. There is also a menu item for “Session Storage” – this is based on the same technology as Local Storage, but the data stored there is deleted when the browser is closed.
Identifying cookies that were set without consent
Listing cookies without consent
With the following steps you can now determine which cookies are set by a website and whether this is done with or without consent:
- As a test example, open www.spotify.com
- Start the developer tools and open the “Application” tab
- Delete all entries in the menu for Local Storage and Cookies as described above
- Click on the menu item Cookies
- Load the page again.
You should now see the page with the content tool, like this:
Since you have not yet interacted with the consent tool to allow cookies, by definition all cookies you see have been set without consent. You can see three “1st party cookies”, i.e. cookies that have the same domain as the website.
If you click on the other areas in the menu, you will also find entries there, such as here under “Local Storage”:
In the case of our example website spotify.com, we have the following first-party cookies:
- OptanonConsent
- sp_landing
- sp_t
Also the following entry in the Local Storage from the domain www.google.com:
rc::a
How can you determine the necessity of a cookie?
The ePrivacy directive prohibits the setting of cookies (or entries in the web storage) that are not necessary for the operation of the website – unless consent has been given. The next step is therefore to determine whether the cookies found are technically necessary. This assessment can be complicated in individual cases (you can read more about this in our article on recognizing technically necessary cookies). However, this assessment is always based on determining the source of the cookies, such as the following:
- The web server software can set cookies, for example to establish a user session or to save status information such as the selected language. This web server software can be a store system such as Shopware or a content management system such as WordPress. In the case of WordPress, it could also be one of the many available plugins.
- If external services such as Google Analytics, Paypal or YouTube are used on a website, these also often set cookies.
It is often difficult to recognize the purpose of cookies set by the web server. It is easier to assess the necessity if a cookie comes from an external service: with a few exceptions (such as cookies from content banners), these cookies are not necessary.
To determine the sources, we use a search engine search. A search for “OptanonConsent cookie” quickly leads to the result that it belongs to the compliance solution “OneTrust”. We can therefore assume that it is necessary because it stores the status of consent.
The source of sp_landing and sp_t is less obvious, but the prefix “sp” could point to Spotify. A search actually shows the following result: “The sp_landing is set by Spotify to implement audio content from Spotify on the website and also registers information on user interaction related to the audio content”. Here, too, one could assume technical necessity.
The web storage entry rc::a is more interesting. A search for “rc::a cookie” leads to search results that lead to privacy statements of various websites in which Google is named as the source, with the purpose “This cookie is used to distinguish between humans and bots. This is beneficial for the website, in order to make valid reports on the use of their website.”
A look at the “Network” tab of the developer tools shows calls to Google servers with the path “www.google.com/recaptcha”:
In fact, Google ReCaptcha is known as an external service to distinguish between humans and “bots” and to prevent bots from accessing the website – so obviously the entry rc::a in the web store is set by Google Recaptcha, and one can now at least argue about the technical necessity.
