Hintergründe

reCAPTCHA-Cookie-Anforderungen: Was festgelegt wird und warum es wichtig ist

Ob reCAPTCHA v2 nur ein Kontrollkästchen zeigt oder eine mehrrundige Bilderauswahl erzwingt, hängt maßgeblich von den Cookies im Browser ab. Ein Browser mit gewachsener Google-Historie gilt als vertrauenswürdiger und bekommt leichtere Abfragen; ein frisches Profil ohne Cookies landet regelmäßig in der schweren Variante. Wer weiß, welche Cookies reCAPTCHA liest und schreibt, erhält den Sitzungszustand gezielt und verbessert die Erfolgsquote in Automatisierungs-Workflows.

Wie Cookies die Schwierigkeit der Abfrage beeinflussen

Google wertet Cookies als eines von vielen Signalen in seiner Risikobewertung. Je plausibler die Browser-Historie wirkt, desto niedriger die Hürde:

Cookie-Zustand Schwierigkeit der Abfrage Grund
Im Google-Konto angemeldet Am niedrigsten Starkes Identitätssignal
Google-Cookies vorhanden (nicht angemeldet) Niedrig–Mittel Deutet auf normale Nutzung hin
Frisches Profil, keine Google-Cookies Mittel–Hoch Keine Historie zur Risikobewertung
Cookies blockiert oder entfernt Hoch Auffällig – normale Browser haben Cookies
Inkognito-/Privatmodus Hoch Keine dauerhafte Identität

Die Risiko-Engine von reCAPTCHA gewichtet Cookies stark:

  1. Bester Fall: Der Browser hat SID-, HSID- und NID-Cookies aus einer angemeldeten Google-Sitzung. → besteht oft allein durch den Klick auf das Kontrollkästchen
  2. Guter Fall: Der Browser hat NID und 1P_JAR aus normalem Surfen. → leichtere Bildabfragen oder direkter Checkbox-Pass
  3. Schlechtester Fall: Keine Google-Cookies, frische Sitzung → mehrrundige Bildabfragen

Cookies in der Automatisierung richtig handhaben

Mit Browser-Automatisierung (Playwright/Puppeteer)

Ein automatisierter Browser verwaltet Cookies von Haus aus. Um sie über Sitzungen hinweg zu erhalten, speichern und laden Sie sie explizit:

# Save cookies after session
cookies = page.context.cookies()
import json
with open("cookies.json", "w") as f:
    json.dump(cookies, f)

# Restore cookies in next session
with open("cookies.json") as f:
    cookies = json.load(f)
page.context.add_cookies(cookies)

Ein typisches DACH-Setup: Ein Scraping-Worker auf einem Hetzner- oder netcup-Server hält pro Ziel-Domain ein persistentes Profil vor – so wächst die Cookie-Historie über Läufe hinweg.

Mit CaptchaAI (reine API-Lösung)

Setzen Sie CaptchaAI ohne eigenen Browser ein, wirken sich Ihre lokalen Cookies nicht direkt auf die Lösung aus – CaptchaAI betreibt seine eigene Lösungsumgebung. Cookies können Sie dennoch mitgeben, falls die Zielseite sie für die Sitzungskontinuität braucht:

POST https://ocr.captchaai.com/in.php

key=YOUR_API_KEY
&method=userrecaptcha
&googlekey=SITE_KEY
&pageurl=https://example.com/login
&cookies=NID=12345;1P_JAR=2026-04-04-12

Der Parameter cookies ist optional und übergibt den Cookie-Kontext zur Lösung an CaptchaAI.

Welche Cookies reCAPTCHA verwendet

Google-Domain-Cookies

Diese werden auf .google.com gesetzt und vom reCAPTCHA-Iframe gelesen:

Cookie Domain Zweck Gültigkeitsdauer
NID .google.com Google-Einstellungen und eindeutige ID 6 Monate
SID / HSID / SSID .google.com Google-Kontositzung (sofern angemeldet) 2 Jahre
APISID / SAPISID .google.com Google-API-Authentifizierung 2 Jahre
1P_JAR .google.com Personalisierung von Google-Anzeigen 1 Monat
CONSENT .google.com Cookie-Einwilligung 17 Jahre

reCAPTCHA-eigene Cookies

Cookie Domain Zweck Gültigkeitsdauer
_GRECAPTCHA .google.com / .recaptcha.net reCAPTCHA-Sitzungsverfolgung Sitzung
rc::a localStorage Daten zur Risikoanalyse Dauerhaft
rc::b localStorage Zeitstempeldaten Sitzung
rc::c localStorage Abfragespezifische Daten Sitzung
rc::d-<id> localStorage Daten pro Widget Sitzung

Cookies der Zielseite

Die Website, die reCAPTCHA einbindet, setzt oft eigene Cookies für Sitzung und CSRF-Schutz:

Cookie-Typ Beispiel Relevanz
Sitzungs-ID PHPSESSID, session_id Bindet die CAPTCHA-Lösung an die Benutzersitzung
CSRF-Token csrf_token, _token Für die Formularübermittlung erforderlich
Eigenes Tracking Seitenspezifisch Kann die CAPTCHA-Auslösung beeinflussen

reCAPTCHA lädt in einem Iframe von google.com. Moderne Browser erzwingen strenge Cookie-Richtlinien:

Browser-Richtlinie Auswirkung auf reCAPTCHA
SameSite=Lax (Standard) Google-Cookies werden im reCAPTCHA-Iframe standardmäßig nicht gesendet
Blockierung von Drittanbieter-Cookies reCAPTCHA weicht auf recaptcha.net oder den Erstanbieter-Modus aus
ITP (Safari) Google-Cookies verfallen schneller, schwere Abfragen häufen sich

Googles Gegenmaßnahmen

Google begegnet den Einschränkungen bei Drittanbieter-Cookies auf drei Wegen:

  • recaptcha.net als alternative Domain
  • localStorage (die rc::*-Einträge) für den clientseitigen Zustand
  • Erstanbieter-Skript-Ladeoptionen für Enterprise-Kunden

localStorage-Einträge

reCAPTCHA legt Risikodaten im localStorage unter Schlüsseln mit dem Präfix rc:: ab:

Schlüsselmuster Daten
rc::a Verschlüsselte Payload für die Risikoanalyse
rc::b Zeitstempel der letzten Abfrage
rc::c Daten der aktuellen Abfrage-Sitzung
rc::d-<hash> Instanzdaten pro Widget

So hält reCAPTCHA den Zustand über Seitenaufrufe, ohne Drittanbieter-Cookies. In der Automatisierung senkt das Erhalten von localStorage die Schwierigkeit der Abfrage:

# Save localStorage
storage = page.evaluate("() => JSON.stringify(localStorage)")
with open("localstorage.json", "w") as f:
    f.write(storage)

# Restore localStorage
with open("localstorage.json") as f:
    storage = f.read()
page.evaluate(f"Object.entries(JSON.parse('{storage}')).forEach(([k,v]) => localStorage.setItem(k,v))")

Best Practices

Maßnahme Nutzen
Browser-Profile zwischen den Läufen beibehalten Baut Historie auf → leichtere Abfragen
Cookies nicht zwischen Aufgaben löschen Erhält die Kontinuität der Google-Risikobewertung
Bei blockiertem google.com auf recaptcha.net ausweichen Gleicher Dienst, andere Domain
Die rc::-Einträge im localStorage erhalten Behält den reCAPTCHA-Sitzungszustand
Gelegentlich Google-Dienste besuchen Frischt die Gültigkeit der Cookies auf

Fehlerbehebung

Problem Ursache Lösung
Dauerhaft schwere Bildabfragen Keine Cookies / frisches Profil Ein Browser-Profil mit Google-Cookies aufbauen und wiederverwenden
Meldung „Cookies erforderlich" Drittanbieter-Cookies blockiert Cookies für google.com erlauben oder recaptcha.net nutzen
Token gültig, aber Sitzung passt nicht Zielseiten-Cookie (PHPSESSID) nicht mitgeführt Alle Cookies sichern und wiederherstellen, nicht nur die von Google
Endlosschleife – immer neue Bildabfragen localStorage zwischen Versuchen geleert Die rc::*-Einträge im localStorage erhalten

Häufige Fragen

Welche Cookies senken die Schwierigkeit am stärksten?

Die Google-Kontocookies SID, HSID und NID. Sie signalisieren eine echte, gewachsene Sitzung und führen häufig dazu, dass ein einfacher Klick auf das Kontrollkästchen genügt.

Muss ich Cookies an CaptchaAI übergeben, damit die Lösung funktioniert?

Nein. CaptchaAI löst reCAPTCHA v2 in seiner eigenen Umgebung, unabhängig von Ihren lokalen Cookies. Der cookies-Parameter ist optional und nur sinnvoll, wenn die Zielseite Cookie-Kontext erwartet.

Was passiert, wenn ich Cookies zwischen den Läufen lösche?

Sie verlieren die aufgebaute Historie, und reCAPTCHA behandelt jeden Lauf wie ein frisches Profil – mit tendenziell schwereren Abfragen. Persistente Profile schlagen hier fast immer den Inkognito-Modus.

Beeinflusst das Blockieren von Drittanbieter-Cookies reCAPTCHA?

Ja. reCAPTCHA weicht dann auf recaptcha.net oder den Erstanbieter-Modus aus und stützt sich stärker auf die rc::*-Einträge im localStorage – deren Erhalt hält die Erfolgsquote stabil.

Sind reCAPTCHA-Cookies nach DSGVO relevant?

Cookies und lokale Kennungen können personenbezogene Daten sein. Wer sie in eigenen Workflows speichert, sollte Rechtsgrundlage und Aufbewahrung nach DSGVO und TTDSG selbst prüfen – das betrifft die Datenverarbeitung, nicht die CAPTCHA-Lösung.


Verwandte Leitfäden

Kommentare sind für diesen Artikel deaktiviert.