Still cookies? Find the Javascript that sets cookies before consent

Finding out which script or API is setting can be a struggle. In some cases, the culprit isn’t an obvious, logically named javascript like:

recaptcha.js or an API with the URL:
fonts.google.com

It might be hidden in a combined script from a page builder, for example, frontend.js from Elementor, which combines javascript and services in one javascript. Or it might be a cached script with a random, hashed name.
Follow the below steps to find the culprit.

Finding a script or plugin that sets cookies using the Developers Console.

We will use really-simple-ssl.com as an example, so you can try what we did if you want. We will search for the script causing the cookie called: “ibx_wpfomo_ip”. First, consider these options before continuing to the developers’ console:

• We will focus on a first-party cookie (own-domain cookie), but it also works for third-party cookies.
• Can you deduct the service from the cookie name? Knowing the service or vendor makes searching scripts easier. Use cookiedatabase.org for more information.
• Be aware that third-party cookies are not always set on logical domains. For example, Adobe sets marketing cookies on demdex.net, and Google Maps might load Google Fonts, etc. We find the cookie “ibx_wpfomo_ip” with the service WPFomify (a WordPress plugin). Source: https://cookiedatabase.org/cookie/wpfomify/ibx_wpfomo_ip/

Using the Developer’s Console

We will not use the service name to find the script but use the approach that works if you don’t know the service at all. If you know the service, you can go through the below quickly.

1. Deactivate all plugins that might minify or combine javascript. Set CloudFlare on Pause if available.
2. Listing all javascript files on your website.

Proceed to your website. Open it in incognito mode and make sure extensions that interfere with scripting are off; AdBlockers and Ghostly are prime examples. Open the developer’s console, either by right-click – ‘inspect’ or going to the top toolbar and selecting View – Developer – Inspect Elements.

Go to the tab network and reload the page. Now filter on scripts by clicking the filter (Funnel) icon and selecting ‘JS’; you should now see something like:

3. Block request URL in developer’s console

The important first step to take, and will save you some trouble is disabling all javascript requests. You can select all requests and right-click, Block request URL. Then right-click again and “Clear browser cookies.” Reload the page and your website is loaded without the requests. Is the cookie still there?

• No. Go to the next step
• Yes. “ibx_wpfomo_ip” is still there if we block all javascript requests. This means we might be looking at a PHP cookie set by the plugin WPFomify. PHP cookies cannot be blocked without removing WPFomify’s full functionality. For this specific WordPress instance, we created CookieShredder. A feature that cleans cookies on the go and hinder its functionality.
• Yes. “ibx_wpfomo_ip” is still there if we block all javascript requests. We should have a look at inline scripts in your page source. To inspect your page source, switch to “Elements” instead of ‘Network’ in Developer’s console.

Inline scripts don’t have a direct request URL, for example:

These scripts mostly use dependencies or inline requests. It is often easy to find which service it provides in these scripts. In the above, you can find ‘Matomo’, and you can find the relevant cookies on cookiedatabase.org to cross-reference. Some scripts implement so-called IDs to reference their service or dependency. You can again cross-reference these services on cookiedatabase.org. If you know which inline script it is, you can easily change the script to:

Or just block matomo.js as seen in this script in the script center.

In this case,  WPFomify is not mentioned in an inline script, thus we conclude this cookie is a PHP cookie. To make sure this is the case, disable the plugin and reload your browser with cleared cookies and cache.

The cookie is set with a javascript file

You know the cookie has disappeared after blocking all requests. This means one (rarely more) javascript file is to blame. And now for the more lengthy part of the operation; trial and error. Unblock all requests before continuing.

Javascript file URL’s on WordPress often carry the plugin or service they’re related to. You can hover on a file name to make sure, then block if it’s a suspect:

Block the request URL. Then proceed to clear cookies, and reload the page.

And continue until you find the culprit. Block the URL in our script center, and you’re done!