chromedevtools/cookie-debugging

Kernkonzepte

HttpOnly vs. Clientseitiger Speicher

Als HttpOnly markierte Cookies können mit clientseitigem JavaScript (cookieStore oder document.cookie) weder gelesen noch geändert werden. Der Browser hängt jedoch aktive HttpOnly-Cookies automatisch an ausgehende HTTP-Anfrageheader (Cookie) an.

• Um aktuelle HttpOnly-Werte zu prüfen: Sehen Sie sich den Cookie-Anfrageheader jeder ausgehenden HTTP-Anfrage via get_network_request an.
• Um zu prüfen, wie Cookies erstellt oder konfiguriert wurden: Sehen Sie sich den Set-Cookie-Antwortheader von Login-/Auth-Antworten an.
• Um Nicht-HttpOnly-Cookies zu prüfen: Verwenden Sie evaluate_script mit der modernen cookieStore-API (async () => await cookieStore.getAll()).

Sitzungsstrategie: Live-Tab vs. Isolierter Kontext

Wählen Sie die richtige Sitzungsumgebung, um State-Kontamination (z. B. restliche Analyse- oder Auth-Tokens) zu vermeiden:

Strategie	Wann verwenden	Einrichtung / Bereinigung
Live-Tab (Aktive Seite)	Diagnose einer aktiven Benutzersitzung, eines Live-401/403-Fehlers oder des aktuellen Zustands.	Arbeitet direkt auf der aktuell ausgewählten Seite.
Clean-Slate (isolatedContext)	Testen von Cookie-Consent-Bannern, Erstbesuchen oder Zero-Cookie-Garantien.	Rufen Sie new_page mit einem eindeutigen isolatedContext auf (z. B. "consent-audit-1"). Rufen Sie nach Abschluss close_page auf.

Clientseitige Fähigkeiten & Einschränkungen

Aktion	Client-JavaScript (cookieStore / document.cookie)	DevTools-Netzwerk- & Kontextwerkzeuge
Nicht-HttpOnly lesen	✅ async () => await cookieStore.getAll()	✅ get_network_request (Anfrage Cookie)
HttpOnly lesen	❌ Von der Browser-Sicherheit blockiert	✅ get_network_request (Anfrage Cookie)
Attribute prüfen (Domain, Path, SameSite, Expires)	✅ async () => await cookieStore.getAll()	✅ get_network_request (Antwort Set-Cookie)
Nicht-HttpOnly ändern / löschen	✅ async () => await cookieStore.set(...)	N/A
HttpOnly ändern / löschen	❌ Stiller Fehlschlag in JavaScript	✅ Verwenden Sie new_page(isolatedContext: ...) für sauberen Zustand

[!WARNING] Der Versuch, ein HttpOnly-Cookie via JavaScript zu löschen (cookieStore.delete oder document.cookie = "...; max-age=0"), schlägt still fehl. Um in einem nicht authentifizierten oder frischen Zustand zu testen, erstellen Sie immer einen neuen isolierten Kontext mit new_page und isolatedContext.

---

Arbeitsablauf-Muster

1. Diagnose von Authentifizierungsfehlern & Weiterleitungen (401 / 403)

Wenn eine authentifizierte Seitenanforderung fehlschlägt, 401/403 zurückgibt oder zur Anmeldeseite weiterleitet:

1. Aktuelle Anfragen auflisten: Rufen Sie list_network_requests mit includePreservedRequests: true auf.
2. Die betreffende Anfrage finden: Suchen Sie die fehlschlagende Anfrage (401/403) oder die Weiterleitung (302/307).
3. Ausgehenden Cookie-Header prüfen: Rufen Sie get_network_request mit der reqid auf.
   • Überprüfen Sie, ob der Cookie-Header angehängt wurde und ob die erforderlichen Tokens (z. B. SESSION_ID, auth_token) gesendet wurden.
4. Aktive Inspektion auslösen (falls keine aktuelle Anfrage vorhanden ist):
   • Wenn das Cookie in einer vorherigen Sitzung gesetzt wurde und kein Netzwerkaufruf aufgelistet ist, lösen Sie eine Anfrage aus:
     • Verwenden Sie navigate_page mit reload: true, ODER
     • Rufen Sie evaluate_script mit () => fetch(window.location.href) auf
   • Rufen Sie dann get_network_request für die neue Anfrage auf, um den aktiven Cookie-Header zu prüfen.
5. Die setzende Anfrage zurückverfolgen: Wenn das Cookie fehlt oder abgelehnt wurde:
   • Überprüfen Sie frühere Login-/Handshake-Antworten auf Set-Cookie-Direktiven:
     • Path-Konflikt: z. B. Path=/api, während die Anfrage an / geht.
     • Domain-Konflikt: z. B. Domain=api.example.com verhindert Cookies auf sub.example.com.
     • Secure-Flag bei HTTP: Secure-Cookies werden niemals über unverschlüsseltes http:// gesendet.
     • SameSite-Blockierung: SameSite=Strict-Cookies werden bei standortübergreifenden Navigationen weggelassen.
     • Ablauf: Prüfen Sie, ob Expires oder Max-Age abgelaufen ist.

2. Cookie-Banner & Consent-Konformitätstests

Um zu überprüfen, dass vor dem Consent oder bei Ablehnung keine nicht notwendigen oder Tracking-Cookies gesetzt werden:

1. Sauber starten: Öffnen Sie einen frischen isolierten Kontext mit einem dedizierten Namen:

   {"url": "<PAGE_URL>", "isolatedContext": "consent-test-1"}
   

2. Basislinien-Cookies erfassen: Bevor Sie mit dem Banner interagieren, führen Sie evaluate_script mit async () => await cookieStore.getAll() aus.
3. Vorzeitige Netzwerkanfragen & Probleme prüfen:
   • Rufen Sie list_network_requests auf, um sicherzustellen, dass vor dem Consent keine Drittanbieter-Tracking-Beacons ausgelöst wurden.
   • Rufen Sie list_console_messages mit types: ["issue"] auf, um auf Tracking-Warnungen zu prüfen.
4. Mit dem Consent-Banner interagieren:
   • Erstellen Sie einen Schnappschuss mit take_snapshot, um die uid des "Ablehnen"- oder "Alle ablehnen"-Buttons zu finden.
   • Klicken Sie den Button mit click.
5. Cookie-Unterschied überprüfen:
   • Führen Sie nach dem Klicken evaluate_script mit async () => await cookieStore.getAll() aus, um sicherzustellen, dass nur unbedingt notwendige oder Consent-Zustands-Cookies vorhanden sind.
6. Consent-Widerruf testen (Lebenszyklus-Audit):
   • Bei der Prüfung des Consent-Widerrufs oder von Präferenzänderungen:
     • Suchen und klicken Sie den "Cookie-Einstellungen"-, "Präferenzen verwalten"- oder Footer-Datenschutzauslöser (take_snapshot $\rightarrow$ click).
     • Deaktivieren Sie nicht notwendige Kategorien oder klicken Sie "Alle widerrufen" / "Einstellungen speichern".
     • Fragen Sie erneut cookieStore.getAll() ab, um zu überprüfen, ob zuvor akzeptierte nicht notwendige Cookies gelöscht oder abgelaufen sind.
     • Rufen Sie list_network_requests für nachfolgende Aktionen auf, um sicherzustellen, dass keine Tracking-Beacons mehr ausgelöst werden.
7. Kontext bereinigen: Rufen Sie close_page auf, wenn das Audit abgeschlossen ist, um zu verhindern, dass übrig gebliebene Cookies nachfolgende Aufgaben beeinträchtigen.

3. Überprüfung der Cookie-Sicherheit, SameSite & CHIPS (Partitionierte Cookies)

1. Schnellweg: Native DevTools-Probleme (Empfohlen):
   • Rufen Sie list_console_messages auf mit:

     {
       "types": ["issue"],
       "includePreservedMessages": true
     }
     

   • Suchen Sie nach CookieIssue-Einträgen wie:
     • SameSiteNoneInsecure: SameSite=None ohne Secure.
     • ThirdPartyCookiePhaseout: Drittanbieter-Cookie blockiert oder eingeschränkt.
     • SchemefulSameSite: Schemaübergreifende Cookie-Probleme.
     • PartitionedCookies: Ungültige CHIPS-Partitionierungsattribute.
2. Tiefenprüfung: Lighthouse Drittanbieter-Cookies:
   • Führen Sie lighthouse_audit mit mode: "navigation" und outputDirPath: "/tmp/lh-report" aus.
   • Extraktion des spezifischen Cookie-Audits ohne den vollständigen Bericht in den Kontext zu laden:

     node -e "const r=require('/tmp/lh-report/report.json'); const a=r.audits['third-party-cookies']; console.log(JSON.stringify({score: a?.score, display