blueredix logo
SCAN On-demand vulnerability scans from €149
high gdpr-tracking-cookie-pre-consent

Tracking cookie set before consent

A tracking cookie was written to the visitor's browser on first page load, before any consent. Same legal failure as a tracker script, and just as easy to fix.

What this means in plain English

The scanner observed at least one cookie matching a known tracker pattern being written to the browser on first page load, before any consent banner could have been clicked. Common cookie names that trigger this finding include _ga, _gid, _gat, and _ga_* (Google Analytics), _fbp and fr (Facebook), _pin_unauth (Pinterest), _hjSession* (Hotjar), mp_* (Mixpanel), intercom-* (Intercom), and __hstc (HubSpot).

These cookies are set either by a third-party script that ran before consent (see our script-before-consent article), or directly by your server-side code in a way that bypasses the consent flow.

Why it matters

The legal analysis is the same as for tracker scripts, with one extra twist. A cookie is unambiguously “storage on the user’s terminal equipment”. There is no academic debate about whether reading or writing it requires consent. TDDDG §25 covers it. ePrivacy Article 5(3) covers it. Every guidance document from European data protection authorities covers it.

What makes this finding particularly common: cookie banners are almost always retrofitted onto existing sites. The cookies were already being set when the banner went live, and the team configuring the banner often forgets to register the existing trackers for deletion when a visitor declines. Visitors then see a banner asking for consent while their browser is already storing the very cookies the banner is supposed to gate.

How to fix it

Two things need to happen.

  1. Stop creating the cookie before consent. Trace the cookie back to its source. If it’s _ga, the source is the GA/GTM script (see the script-before-consent article). If it’s a first-party cookie set by your own backend (session_id, analytics_id), restructure your code so the cookie is set only after consent.

  2. Delete the cookies that already exist on returning visitors. Add to your consent platform’s “decline” handler an instruction to overwrite the tracker cookies with Max-Age=0 (or Expires in the past). Most modern consent platforms do this automatically once you register the cookies in their configuration.

Verify in a fresh incognito window. Open developer tools, go to the Application tab, then Cookies, then your domain. Before clicking “Accept” on the banner, the only cookies should be the consent platform’s own cookies (typical names include cookieyes-consent, borlabs-cookie, and CookieConsent) plus cookies strictly necessary for the site (CSRF token, session, language preference). Anything starting with _ga, _fbp, _hjSession*, or _pin_* is a finding.

A note on first-party server-side analytics

Self-hosted, IP-anonymising analytics (Plausible, privacy-configured Matomo, Umami) running on your own subdomain typically don’t need consent. They don’t use cookies and don’t transmit personal data to a third party. The blueredix scanner specifically excludes these patterns from this finding. If you saw the finding, it is because at least one cookie matched a known third-party tracker, not a privacy-friendly self-hosted analytics tool.

Further reading