Explainers

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

reCAPTCHA liest und schreibt Cookies, um das Risiko einzuschätzen. Ein Browser mit frischen Google-Cookies steht vor größeren Herausforderungen als einer ohne Cookies. Wenn Sie wissen, welche Cookies reCAPTCHA verwendet, können Sie den Sitzungsstatus aufrechterhalten und die Lösungsergebnisse in Ihren Automatisierungsworkflows verbessern.

Verwendung von Cookies durch reCAPTCHA

Google Domain-Cookies

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

Keks Domäne Zweck Lebenszeit
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-Einwilligungspräferenz 17 Jahre

reCAPTCHA-spezifische Cookies

Keks Domäne Zweck Lebenszeit
_GRECAPTCHA .google.com / .recaptcha.net reCAPTCHA-Sitzungsverfolgung Sitzung
rc::a lokaler Speicher Daten zur Risikoanalyse Anhaltend
rc::b lokaler Speicher Zeitstempeldaten Sitzung
rc::c lokaler Speicher Herausforderungsspezifische Daten Sitzung
rc::d-<id> lokaler Speicher Daten pro Widget Sitzung

Zielseiten-Cookies

Die Website, die reCAPTCHA hostet, kann auch Cookies für die Sitzungs- und CSRF-Verfolgung verwenden:

Cookie-Typ Beispiel Relevanz
Sitzungs-ID PHPSESSID, session_id Bindet die CAPTCHA-Lösung an die Benutzersitzung
CSRF-Token csrf_token, _token Erforderlich für die Formularübermittlung
Benutzerdefinierte Nachverfolgung Standortspezifisch Kann die CAPTCHA-Auslösung beeinträchtigen

Wie sich Cookies auf die Herausforderungsschwierigkeit auswirken

Google verwendet Cookies als eines von vielen Signalen in seiner Risikobewertung:

Cookie-Status Herausforderungsschwierigkeit Warum
Im Google-Konto angemeldet Am niedrigsten Starkes Identitätssignal
Google-Cookies vorhanden (nicht angemeldet) Niedrig–Mittel Zeigt den normalen Browserverlauf an
Neuer Browser, keine Google-Cookies Mittel–Hoch Keine Anamnese zur Risikobeurteilung
Cookies blockiert oder entfernt Hoch Verdächtig – normale Browser verfügen über Cookies
Inkognito-/privater Modus Hoch Keine dauerhafte Identität

Die Risiko-Engine von reCAPTCHA legt großen Wert auf Cookies:

  1. Bester Fall: Der Browser verfügt über SID-, HSID- und NID-Cookies aus einer angemeldeten Google-Sitzung. → besteht häufig nur beim Klicken auf das Kontrollkästchen
  2. Guter Fall: Der Browser verfügt über NID und 1P_JAR im Vergleich zum normalen Surfen. → erleichtert Bildherausforderungen oder Kontrollkästchen
  3. Worst Case: Keine Google-Cookies, neue Sitzung → Multi-Runden-Image-Herausforderungen

Umgang mit Cookies in der Automatisierung

Mit Browser-Automatisierung (Playwright/Puppeteer)

Die Browserautomatisierung verarbeitet Cookies natürlich. Um sie zwischen Sitzungen aufzubewahren:

# 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)

Mit CaptchaAI (Nur-API-Lösung)

Wenn Sie CaptchaAI ohne Browser verwenden, wirken sich Cookies nicht direkt auf die Lösung aus – CaptchaAI verwaltet seine eigene Lösungsumgebung. Möglicherweise möchten Sie jedoch Cookies weitergeben, wenn die Zielseite sie für die Sitzungskontinuität benötigt:

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 sendet Cookie-Kontext zur Lösung an CaptchaAI.

Einschränkungen für domänenübergreifende Cookies

reCAPTCHA wird in einem Iframe von google.com geladen. Moderne Browser erzwingen strenge Cookie-Richtlinien:

Browserrichtlinie Auswirkung auf reCAPTCHA
SameSite=Lax (Standard) Google-Cookies werden standardmäßig nicht im reCAPTCHA-Iframe gesendet
Blockierung von Cookies von Drittanbietern reCAPTCHA greift auf den recaptcha.net- oder Erstanbietermodus zurück
ITP (Safari) Google-Cookies verfallen schneller, schwierigere Herausforderungen treten häufiger auf

Googles Abhilfemaßnahmen

Google geht auf die Cookie-Beschränkungen von Drittanbietern ein, indem es:

  • Verwendung von recaptcha.net als alternative Domäne
  • Verwendung von localStorage (rc::*-Einträge) für den clientseitigen Status
  • Verwendung von Optionen zum Laden von Erstanbieter-Skripten für Unternehmenskunden

localStorage-Einträge

reCAPTCHA speichert Risikobewertungsdaten in localStorage unter den vorangestellten Schlüsseln rc:::

Schlüsselmuster Daten
rc::a Verschlüsselte Nutzlast für die Risikoanalyse
rc::b Zeitstempel der letzten Herausforderung
rc::c Aktuelle Challenge-Sitzungsdaten
rc::d-<hash> Instanzdaten pro Widget

Diese Einträge helfen reCAPTCHA, den Status über Seitenladevorgänge hinweg aufrechtzuerhalten, ohne auf Cookies von Drittanbietern angewiesen zu sein. Bei der Automatisierung kann die Beibehaltung von localStorage die Herausforderungsschwierigkeit verringern:

# 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
Behalten Sie Browserprofile zwischen den Läufen bei Erstellt den Browserverlauf → einfachere Herausforderungen
Löschen Sie Cookies nicht zwischen Aufgaben Gewährleistet die Kontinuität der Risikobewertung von Google
Verwenden Sie recaptcha.net, wenn google.com blockiert ist Gleicher Dienst, andere Domain
Behalten Sie die localStorage rc::-Einträge bei Behält den reCAPTCHA-Sitzungsstatus bei
Besuchen Sie gelegentlich Google-Eigenschaften Aktualisiert die Gültigkeit des Cookies

Fehlerbehebung

Problem Ursache Lösung
Ergebnis passt nicht zum eigenen Fall Solver-Typ oder Eingabeparameter wurden falsch auf den Zieltyp gemappt Vergleiche Zielseite, Solver-Methode und Pflichtparameter noch einmal systematisch
Beispiel läuft, aber Produktion scheitert Session, Header oder Proxy-Kontext weichen vom Test ab Übertrage erfolgreiche Testbedingungen möglichst unverändert in den Live-Workflow
Fehler bleiben unklar Logs enthalten zu wenig Kontext für eine belastbare Diagnose Protokolliere Solver-Typ, Latenz, Fehlercode und Downstream-Reaktion gemeinsam

Verwandte Leitfäden

  • reCAPTCHA Cookie- und Session-Anforderungen
  • reCAPTCHA data-s Parameter erklärt
  • Warum reCAPTCHA v3 niedrige Scores liefert
Kommentare sind für diesen Artikel deaktiviert.

Verwandte Beiträge

Explainers Leitfaden zur reCAPTCHA-Anker- und Bframe-URL-Extraktion
Klarer Überblick zu Leitfaden zur re CAPTCHA-Anker- und Bframe-URL-Extraktion und dazu, was das für Automatisierung, Integration und Erfolgsquoten mit Captcha A...

Klarer Überblick zu Leitfaden zur re CAPTCHA-Anker- und Bframe-URL-Extraktion und dazu, was das für Automatisi...

Apr 28, 2026
Comparisons Headless vs. Headed Chrome für CAPTCHA-Tests in eigener QA
Wann sich Headless-Chrome und wann Headed-Chrome für CAPTCHA-Tests in eigenen CI- und QA-Pipelines eignet, und welche Auswirkungen die Wahl auf Stabilität und L...

Wann sich Headless-Chrome und wann Headed-Chrome für CAPTCHA-Tests in eigenen CI- und QA-Pipelines eignet, und...

Apr 17, 2026