Cookies in Chrome bearbeiten

TL;DR: Um Cookies in Chrome zu bearbeiten, öffne die DevTools (F12) → Application → Cookies, dann doppelklicke auf jede Zelle, um Wert, Ablauf, SameSite, HttpOnly oder Secure-Flags zu ändern. Für einen schnelleren Ablauf ohne DevTools installiere CookieVault Editor und bearbeite Cookies inline aus dem Symbolleisten-Popup. Beide Methoden ändern den Cookie-Speicher sofort.

Cookies in Chrome zu bearbeiten ist eine Browser-Operation, die dich den Wert, das Ablaufdatum, die Domain, den Pfad und die Sicherheits-Flags jedes für eine bestimmte Website gespeicherten Cookies ändern lässt. Die Hauptanwendungen sind das Debuggen von Sitzungs-Bugs, das Testen des Verhaltens pro Flag (SameSite, Secure, HttpOnly), das Reproduzieren von nutzergemeldeten Problemen und das Verlängern von Sitzungs-Laufzeiten während der Entwicklung. Chrome bietet zwei zuverlässige Methoden — das eingebaute DevTools-Application-Panel und eine Manifest-V3-Erweiterung — jede für unterschiedliche Abläufe geeignet1.

Schnellvergleich: DevTools vs. Erweiterung

Kurz gesagt: Die DevTools sind eingebaut und erfordern keine Installation, brauchen aber mehrere Klicks pro Bearbeitung. Eine Erweiterung bietet einen schnelleren, wiederholbaren Ablauf aus der Symbolleiste — besonders beim Bearbeiten von Cookies über mehrere Domains hinweg oder beim wiederholten Vornehmen derselben Änderung.

FähigkeitDevTools (eingebaut)CookieVault Editor (Erweiterung)
Cookie-Wert bearbeitenJa — Doppelklick auf ZelleJa — Inline-Feld
Ablauf / Max-Age bearbeitenJa — Doppelklick auf ZelleJa — Datumsauswahl
SameSite / Secure / HttpOnly bearbeitenJa — Doppelklick auf ZelleJa — Umschalter
Cookies für andere Domains bearbeitenNur wenn diese Domain auf der aktuellen Seite gesetzt hatJa — jede Domain via chrome.cookies-API
Neues Cookie anlegenJa — auf leere Zeile unten klickenJa — Schaltfläche “Add cookie”
Vor dem Bearbeiten exportieren (Sicherung)NeinJa — JSON / Netscape / HAR
Mehrere Cookies in einem Rutsch bearbeitenNeinJa — Mehrfachauswahl + Massenbearbeitung
Funktioniert im InkognitomodusJaJa (falls für Inkognitomodus aktiviert)

Die Dokumentation des Chrome-DevTools-Application-Panels beschreibt die Cookie-Tabelle als “ein editierbares Spreadsheet” zur Inspektion und Änderung von Cookies während der Entwicklung1. Für Produktions-Debugging und QA-Abläufe, die wiederholte Bearbeitungen beinhalten, reduziert eine Erweiterung die Anzahl der Schritte pro Bearbeitung von sechs auf zwei.

Methode 1: Chrome DevTools (der eingebaute Weg)

Kurz gesagt: Die DevTools geben dir direkten Zugriff auf jedes Cookie-Attribut in Tabellenform. Doppelklick auf eine Zelle zum Bearbeiten. Die Änderung greift sofort im Cookie-Speicher — lade die Seite neu, um den serverseitigen Effekt zu sehen. Acht Schritte vom Öffnen der DevTools bis zur überprüften Bearbeitung.

Der achtstufige DevTools-Workflow zur Cookie-Bearbeitung:

  1. Zielwebsite öffnen — navigiere zu der Website, deren Cookies du bearbeiten willst. Die Cookies müssen bereits im Speicher deines Browsers für diese Domain existieren.
  2. Chrome DevTools öffnen — drücke F12 (oder Strg+Umschalt+I unter Windows/Linux, Cmd+Option+I auf dem Mac). Du kannst auch mit der rechten Maustaste auf die Seite klicken und “Untersuchen” wählen.
  3. Zum Application-Tab navigieren — klicke in der oberen Leiste der DevTools auf “Application”. Falls der Tab nicht sichtbar ist, klicke auf den Chevron (>>), um das Überlaufmenü zu erweitern.
  4. Cookies in der linken Seitenleiste erweitern — unter “Storage” erweitere “Cookies”. Du siehst die Hauptdomain plus alle Drittanbieter-Domains, die auf dieser Seite Cookies gesetzt haben.
  5. Auf die Zieldomain klicken — das Hauptpanel zeigt eine Tabelle mit Name, Value, Domain, Path, Expires, Size, HttpOnly, Secure, SameSite und Priority.
  6. Doppelklick auf eine Zelle zum Bearbeiten — die Zelle wird zum Eingabefeld. Ändere den Wert und drücke Enter. Editierbare Felder sind Value, Expires/Max-Age, Domain, Path, SameSite, Secure und HttpOnly.
  7. Enter drücken, um zu übernehmen — der Cookie-Speicher wird sofort aktualisiert. Kein Bestätigungsdialog; kein Rückgängig.
  8. Seite neu laden zur Überprüfung — drücke F5. Die Website erhält das geänderte Cookie nun bei der nächsten Anfrage. Bestätige das erwartete Verhalten.

Wichtig: Das Bearbeiten des Name-Felds benennt das Cookie nicht um — es löscht das alte Cookie und erstellt ein neues mit dem neuen Namen. Wenn du nur den Wert ändern willst, lass das Name-Feld unangetastet.

Methode 2: CookieVault Editor (Erweiterung)

Kurz gesagt: CookieVault Editor bietet ein Symbolleisten-Popup mit Inline-Bearbeitung — klicke auf ein Cookie, ändere ein Feld, klicke auf Save. Keine DevTools nötig. Die Erweiterung nutzt Chromes chrome.cookies-API, was bedeutet, dass sie HttpOnly-Cookies bearbeiten und auf Cookies jeder Domain zugreifen kann, nicht nur der aktuellen Seite.

Der achtstufige Erweiterungs-Workflow:

  1. CookieVault Editor installieren — aus dem Chrome Web Store. Die Erweiterung fragt die Berechtigungen cookies und tabs an, die zum Lesen und Schreiben von Cookies nötig sind.
  2. Zur Zielwebsite navigieren — öffne die Website, deren Cookies du bearbeiten willst.
  3. Auf das Symbol in der Symbolleiste klicken — das Popup listet alle Cookies der aktuellen Domain, gruppiert nach First-Party und Third-Party.
  4. Auf einen Cookie-Namen klicken — die Detailansicht öffnet sich und zeigt Value, Domain, Path, Expires, SameSite, Secure, HttpOnly und Size.
  5. Felder bearbeiten — jedes Feld inline ändern. SameSite, Secure und HttpOnly sind Umschalter. Expires hat eine Datumsauswahl. Value ist ein Texteingabefeld.
  6. Auf Save klicken — die Erweiterung schreibt das aktualisierte Cookie via chrome.cookies.set(). Die Änderung greift sofort.
  7. Überprüfen — lade die Seite neu oder beobachte das Network-Panel, um zu bestätigen, dass das geänderte Cookie mit der nächsten Anfrage gesendet wird.
  8. Optional: vor dem Bearbeiten exportieren — für unumkehrbare Sitzungen (Banking, Admin-Panels) zuerst als JSON exportieren. Wenn die Bearbeitung deine Sitzung kaputtmacht, importiere die Sicherung, um wiederherzustellen.

Der Erweiterungs-Workflow ist besonders effizient für QA-Ingenieure, die täglich Cookies auf Dutzenden Test-Domains bearbeiten müssen, oder für Entwickler, die das SameSite-Verhalten über mehrere Origins hinweg testen.

Kurz gesagt: Die häufigsten Gründe, ein Cookie zu bearbeiten, sind das Verlängern einer Sitzung, das Testen des SameSite-Verhaltens, das Simulieren eines anderen Nutzers und das Debuggen von CSRF-Token-Konflikten. Jedes Szenario entspricht einer bestimmten Feldbearbeitung.

Sechs praktische Szenarien, in denen das Bearbeiten von Cookies die richtige Debugging-Technik ist:

  • Eine Sitzung beim Debugging verlängern — doppelklicke auf die Expires-Zelle und setze ein weit in der Zukunft liegendes Datum (z. B. ein Jahr ab heute). Das verhindert, dass die Sitzung abläuft, während du durch den Code gehst. Nützlich beim Debuggen langer mehrstufiger Formulare.
  • SameSite-Verhalten testen — ändere SameSite von Lax auf Strict, um zu überprüfen, dass die websiteübergreifende Navigation die Authentifizierung wie erwartet bricht. Ändere auf None (mit Secure = true), um zu bestätigen, dass Cross-Origin-iframe-Einbettung funktioniert.
  • Einen anderen Nutzer simulieren — kopiere einen Sitzungs-Cookie-Wert aus einem Browser-Profil und füge ihn in ein anderes ein. Das reproduziert den exakten Sitzungszustand ohne erneute Anmeldung. Funktioniert nur, wenn der Server Sitzungen nicht an IP oder User-Agent bindet.
  • CSRF-Token-Konflikte debuggen — CSRF-Tokens werden oft in Cookies gespeichert (csrftoken, XSRF-TOKEN). Das Bearbeiten des Cookie-Werts auf einen bekannt schlechten Wert bestätigt, dass der Server die Anfrage ablehnt, und validiert den CSRF-Schutz.
  • Ein Cookie auf Nur-Secure erzwingen — setze das Secure-Flag auf true auf einem Cookie und überprüfe, dass die Website beim Laden über HTTP kaputtgeht. Das bestätigt, dass die Website das Secure-Flag in Mixed-Content-Szenarien korrekt handhabt.
  • Cookie-Pfad-Scoping testen — ändere den Path von / auf /admin und überprüfe, dass das Cookie nicht mehr bei Anfragen an /dashboard gesendet wird. Das validiert das pfad-skopierte Cookie-Verhalten.

Kurz gesagt: Chrome stellt acht bearbeitbare Attribute pro Cookie bereit. Jedes Attribut steuert einen anderen Aspekt davon, wann, wo und wie das Cookie gesendet wird. Sie zu verstehen ist essenziell für effektives Debugging.

AttributWas es steuertBeispielbearbeitung
ValueDie an den Server gesendete Daten-PayloadSitzungs-ID ändern, um Session Fixation zu testen
DomainWelche Domains das Cookie erhalten.example.com zu app.example.com ändern, um den Scope zu begrenzen
PathWelche URL-Pfade das Cookie erhalten/ zu /api ändern, um die Übertragung zu begrenzen
Expires / Max-AgeWann das Cookie vom Browser gelöscht wirdVerlängern, um langlebige Sitzungen zu testen
SecureCookie wird nur über HTTPS gesendetUmschalten, um Mixed-Content-Verhalten zu testen
HttpOnlyCookie ist für document.cookie unzugänglichUmschalten, um XSS-Cookie-Diebstahl-Szenarien zu testen
SameSiteCross-Site-Senderegeln (Strict / Lax / None)Ändern, um CSRF und iframe-Einbettung zu testen
PriorityRäumungsreihenfolge bei Erreichen des Cookie-LimitsAuf Low ändern, um zu testen, welche Cookies Chrome zuerst verwirft

Das Chromium-Projekt erzwingt ein Limit von etwa 180 Cookies pro Domain. Wenn dieses Limit erreicht wird, räumt Chrome Cookies in der Reihenfolge der Priority (Low zuerst, dann Medium, dann High) und innerhalb jeder Priority-Stufe nach dem Zeitstempel des am wenigsten kürzlich genutzten Zugriffs2.

Einschränkungen und Sonderfälle

Kurz gesagt: Einige Cookie-Bearbeitungen sind durch Browser-Sicherheitsrichtlinien eingeschränkt. Diese Limits zu kennen verhindert verlorene Debugging-Zeit.

  • Cross-Origin-Cookies — du kannst keine Cookies für eine Domain bearbeiten, die auf der aktuellen Seite kein Cookie gesetzt hat (in den DevTools). Nutze eine Erweiterung für Cross-Domain-Zugriff.
  • Partitionierte Cookies (CHIPS) — Chromes Partitioned-Cookies-Funktion bedeutet, dass derselbe Cookie-Name je nach Top-Level-Site unterschiedliche Werte haben kann. Das Bearbeiten einer Partition beeinflusst die anderen nicht.
  • Serverseitige Validierung — das Ändern eines Sitzungs-Cookie-Werts auf einen beliebigen String schlägt serverseitig fehl. Der Server behandelt den geänderten Wert als ungültige Sitzung und stellt bei der nächsten Antwort ein neues Cookie aus.
  • Cookie-Größenlimits — ein einzelnes Cookie darf etwa 4.096 Bytes (Name + Wert zusammen) nicht überschreiten. Die DevTools schneiden Werte, die dieses Limit übersteigen, stillschweigend ab.
  • __Host- und __Secure--Präfixe — Cookies mit diesen Namens-Präfixen unterliegen zusätzlichen Einschränkungen. Ein __Host--präfigiertes Cookie muss Secure = true, Path = / und kein Domain-Attribut haben. Das Bearbeiten dieser Attribute, sodass die Präfix-Regeln verletzt werden, führt dazu, dass Chrome das Cookie ablehnt.
  • Abschaltung von Drittanbieter-Cookies — während Chrome Drittanbieter-Cookies auslaufen lässt, kann das Bearbeiten von Drittanbieter-Cookies in den DevTools Warnungen zeigen oder bei Websites, die in der Privacy Sandbox eingeschrieben sind, keinen Effekt haben.

Siehe auch


Footnotes

  1. Die offizielle Chrome-DevTools-Dokumentation zur Cookie-Inspektion, -Bearbeitung und -Löschung steht unter https://developer.chrome.com/docs/devtools/storage/cookies. Die Cookie-Tabelle des Application-Panels unterstützt die Inline-Bearbeitung aller Standard-Cookie-Attribute. 2

  2. Chromiums Cookie-Speicher-Limits und Räumungsverhalten sind im Chromium-Quellcode dokumentiert und in den Chrome-Platform-Status-Einträgen für Cookie-bezogene Funktionen besprochen. Das Näherungslimit von 180 Cookies pro Domain und die prioritätsbasierte Räumungsreihenfolge sind Implementierungsdetails, die über Chrome-Versionen hinweg stabil waren.

Zuletzt aktualisiert:

Autor: Lena Park · Geprüft von: Marcus Reiter