blueredix logo
high gdpr-tracking-cookie-pre-consent

Tracking-Cookie vor Einwilligung gesetzt

Ein Tracking-Cookie wurde beim ersten Seitenaufruf in den Browser geschrieben, bevor eine Einwilligung erteilt war. Rechtlich derselbe Verstoß wie ein Tracker-Skript, und genauso einfach zu beheben.

Worum es geht

Der Scanner hat beim ersten Seitenaufruf mindestens einen Cookie mit bekanntem Tracker-Muster im Browser gesehen, bevor ein Consent-Banner hätte geklickt sein können. Häufige Cookie-Namen, die den Befund auslösen, sind _ga, _gid, _gat und _ga_* (Google Analytics), _fbp und fr (Facebook), _pin_unauth (Pinterest), _hjSession* (Hotjar), mp_* (Mixpanel), intercom-* (Intercom) sowie __hstc (HubSpot).

Solche Cookies werden entweder von einem vor der Einwilligung geladenen Drittanbieter-Skript gesetzt (siehe unseren Skript-vor-Einwilligung-Artikel), oder direkt von Ihrem serverseitigen Code, der den Consent-Fluss umgeht.

Warum das wichtig ist

Rechtlich gilt dieselbe Analyse wie bei Tracker-Skripten, mit einer Verschärfung. Ein Cookie ist unzweifelhaft “Speicherung auf dem Endgerät”. Daran gibt es keinerlei akademische Diskussion. TDDDG §25 regelt es. Art. 5(3) ePrivacy regelt es. Sämtliche Aufsichtsbehörden-Hinweise regeln es.

Was den Befund besonders häufig macht: Cookie-Banner werden meist nachträglich auf bestehende Seiten aufgesetzt. Die Cookies waren schon da, als der Banner live ging, und das Team, das den Banner konfiguriert, vergisst oft, die bestehenden Tracker für die Löschung beim Ablehnen zu registrieren. Besucher:innen sehen dann einen Banner, der nach Einwilligung fragt, während der Browser genau die Cookies, die der Banner schützen soll, längst gespeichert hat.

So beheben Sie das

Zwei Dinge müssen passieren.

  1. Cookie-Erzeugung vor Einwilligung stoppen. Quelle des Cookies zurückverfolgen. Ist es _ga, ist die Quelle das GA/GTM-Skript (siehe Skript-vor-Einwilligung-Artikel). Ist es ein First-Party-Cookie aus Ihrem eigenen Backend (session_id, analytics_id), strukturieren Sie den Code so um, dass das Cookie erst nach Einwilligung gesetzt wird.

  2. Bestandscookies bei Ablehnung löschen. Im “Ablehnen”-Handler Ihrer Consent-Plattform eine Anweisung ergänzen, die die Tracker-Cookies mit Max-Age=0 (oder Expires in der Vergangenheit) überschreibt. Die meisten modernen Plattformen erledigen das automatisch, sobald die Cookies in ihrer Konfiguration registriert sind.

Prüfen in einem frischen Inkognito-Fenster. Entwicklertools öffnen, auf den Tab “Anwendung” gehen, dann Cookies, dann Ihre Domain. Vor dem “Akzeptieren” dürfen nur die Plattform-eigenen Cookies (typisch: cookieyes-consent, borlabs-cookie, CookieConsent) plus für die Seite zwingend erforderliche Cookies (CSRF-Token, Session, Sprachauswahl) sichtbar sein. Alles, was mit _ga, _fbp, _hjSession* oder _pin_* beginnt, ist ein Befund.

Hinweis zu eigener serverseitiger Analytics

Selbst gehostete, IP-anonymisierende Analytics-Lösungen (Plausible, datenschutzfreundlich konfiguriertes Matomo, Umami) auf einer eigenen Subdomain brauchen typischerweise keine Einwilligung. Sie verwenden keine Cookies und übertragen keine personenbezogenen Daten an Dritte. Der blueredix-Scanner schließt solche Muster vom Befund explizit aus. Wenn Sie den Befund sehen, ist mindestens ein Cookie zu einem bekannten Drittanbieter-Tracker zugeordnet, nicht zu einer datenschutzfreundlichen Eigenlösung.

Mehr dazu