Cookies: document.cookie

Cookies sind kleine Datenpakete (max. ca. 4 KB pro Stück), die eine Website im Browser speichert und die bei jeder Anfrage an denselben Ursprung automatisch mitgesendet werden. Genau das unterscheidet sie von anderen clientseitigen Speichermechanismen: Cookies reisen zum Server mit, weshalb sie der klassische Mechanismus für Session-Bezeichner, „Eingeloggt bleiben"-Tokens sowie Sprach- oder Theme-Einstellungen sind, die der Server kennen muss. Dieser Leitfaden erklärt, wie man Cookies mit document.cookie liest, schreibt und löscht, welche Attribute ihren Gültigkeitsbereich und ihre Lebensdauer steuern und wann eine andere Speicheroption sinnvoller ist.

So funktioniert document.cookie

document.cookie ist eine täuschend einfache Eigenschaft. Beim Lesen gibt sie alle Cookies des aktuellen Dokuments als einen semikolongetrennten String aus name=value-Paaren zurück. Beim Schreiben wird ein Cookie auf einmal gesetzt — und entscheidend: Eine Zuweisung überschreibt nicht den gesamten String. Der Browser parst die Zuweisung und fügt dieses eine Cookie in die vorhandene Menge ein:

// Reading: returns everything as one string
document.cookie; // "theme=dark; lang=en; sessionId=abc123"

// Writing: adds/updates ONE cookie, leaves the rest intact
document.cookie = "username=John";

Die angehängten Attribute (path, expires, Secure, …) sind schreibgeschützt — sie konfigurieren das Cookie, erscheinen aber nie beim Lesen von document.cookie. Zurückgeliefert werden immer nur name=value-Paare.

Ein Cookie erstellen

Um ein Cookie zu erstellen, weist man document.cookie einen name=value-String zu, optional gefolgt von durch ; getrennten Attributen. Enthält der Wert Leerzeichen, Semikolons oder andere Sonderzeichen, sollte man ihn mit encodeURIComponent kodieren, damit das Parsen nicht fehlschlägt:

Damit wird ein Cookie namens username mit dem Wert John Doe (enkodiert, um das Leerzeichen zu verarbeiten) erstellt, das am 8. Juni 2025 abläuft und auf der gesamten Website zugänglich ist (path=/).

Cookie-Attribute

Attribute werden an den Zuweisungsstring angehängt und steuern, wohin das Cookie gesendet wird und wie lange es gültig ist. Die wichtigsten:

Ohne expires oder max-age entsteht ein Session-Cookie, das beim Schließen des Browsers verschwindet.

Ein Ablaufdatum setzen

Mit expires legt man ein absolutes Datum fest, mit max-age eine relative Lebensdauer in Sekunden. max-age ist meist einfacher, weil kein Datum formatiert werden muss:

Dieses userSettings-Cookie läuft 24 Stunden (86.400 Sekunden) nach seiner Erstellung ab.

Ein einzelnes Cookie lesen

Da document.cookie alle Cookies in einem einzigen String zurückgibt, muss dieser geparst werden, um an einen einzelnen Wert zu kommen. Eine robuste Hilfsfunktion stellt dem String ; voran, damit dieselbe Aufteilung für das erste Cookie genauso funktioniert wie für jedes andere:

Wenn man alle Cookies durchlaufen möchte, teilt man auf ; auf und parst jedes Paar einzeln:

Ein Cookie löschen

Es gibt keinen „Löschen"-Befehl — ein Cookie wird gelöscht, indem man es mit einem Ablaufdatum in der Vergangenheit (oder max-age=0) neu setzt. Die häufigste Falle dabei: Man muss denselben path und domain verwenden, mit dem das Cookie erstellt wurde, andernfalls behandelt der Browser es als anderes Cookie und lässt das Original bestehen.

Das Setzen von expires=Thu, 01 Jan 1970 00:00:00 UTC erreicht dasselbe für Browser, die expires gegenüber max-age bevorzugen.

Cookies absichern

Wenn ein Cookie etwas Sensibles enthält (vor allem ein Session-Token), sind die Attribute genauso wichtig wie der Wert:

• Secure — sendet das Cookie nur über HTTPS, sodass es nicht über eine unverschlüsselte HTTP-Verbindung durchsickern kann.
• SameSite — steuert, ob das Cookie bei Cross-Site-Anfragen mitgesendet wird. Lax (der moderne Standard) blockiert es bei den meisten Cross-Site-Anfragen und mindert damit CSRF-Risiken; Strict ist am restriktivsten; None (das Secure erfordert) ist für echte Cross-Site-Szenarien gedacht.
• HttpOnly — verbirgt das Cookie vollständig vor JavaScript und schützt Session-Tokens vor XSS-Diebstahl. Es kann nicht über document.cookie gesetzt werden; der Server muss es über den Set-Cookie-Response-Header senden. Deshalb werden Session-Cookies typischerweise serverseitig verwaltet.

document.cookie = "sessionId=abc123; expires=Sat, 08 Jun 2025 12:00:00 UTC; path=/; Secure; SameSite=Lax";

Cookies vs. localStorage

Cookies sind nicht der einzige clientseitige Speicher, und für die meisten Daten sind sie nicht die beste Wahl. Cookies sollte man nur verwenden, wenn der Server die Daten bei jeder Anfrage benötigt:

Wenn man sich nur etwas auf dem Client merken möchte und der Server es nie liest, ist localStorage oder sessionStorage einfacher und geräumiger; die Storage API behandelt das ausführlich. Da Cookies automatisch mit Anfragen mitgesendet werden, interagieren sie auch mit CORS-Regeln — siehe Cross-Origin-Anfragen mit Fetch für das Senden von Anmeldeinformationen über Ursprungsgrenzen hinweg.

Fazit

Cookies sind nach wie vor der Standardweg, um kleine Zustandsinformationen mit dem Server zu teilen — Sessions, Authentifizierung und serverseitig gelesene Einstellungen. Man schreibt sie einzeln mit document.cookie, begrenzt ihren Gültigkeitsbereich mit path/domain, steuert ihre Lebensdauer mit expires/max-age und sichert sie mit Secure, SameSite und (serverseitig) HttpOnly. Für größere, nur clientseitige Daten empfiehlt sich stattdessen Web Storage.

Übungen