Cookies verstehenRatgeber

Cookie-Attribute: Secure, HttpOnly und SameSite

Attribute legen fest, wie lange ein Cookie gilt, an welche Adressen er geht und unter welchen Bedingungen der Browser ihn mitschickt. Secure erlaubt die Übertragung nur über HTTPS, HttpOnly sperrt den Zugriff durch Skripte, und SameSite steuert, ob der Cookie bei Anfragen von fremden Websites mitgeht. Fehlt SameSite, behandeln Chromium-Browser den Cookie wie SameSite=Lax.

Kleine Pappschachteln mit verschiedenfarbigen Bändern auf einer Werkbank, in jeder liegt ein runder Keks
Bild: KI-generiert

Ein Server setzt einen Cookie mit der Kopfzeile Set-Cookie. Pflicht ist nur das Paar aus Name und Wert, dahinter folgen durch Semikolon getrennt die Attribute [1]. Eine Zeile wie "Set-Cookie: id=a3fWa; Max-Age=2592000; Secure; HttpOnly; SameSite=Lax" legt einen Cookie an, der 30 Tage gilt, nur über HTTPS übertragen wird, für Skripte unsichtbar bleibt und bei den meisten Anfragen von fremden Websites zurückbleibt. Wer mehrere Cookies setzen will, schickt mehrere Set-Cookie-Zeilen in derselben Antwort [1]. Grundlage ist die Norm RFC 6265 aus dem April 2011 [3]. Der Cookie-Checker zeigt die wichtigsten dieser Angaben für jede geprüfte Website.

Name und Wert

Der Name darf keine Steuerzeichen und keine Trennzeichen wie Leerzeichen, Klammern, Komma, Semikolon oder Gleichheitszeichen enthalten. Der Wert darf in Anführungszeichen stehen, aber keine Leerzeichen, Kommas, Semikolons oder Backslashes enthalten [1]. Viele Anwendungen kodieren den Wert deshalb mit Prozentzeichen, obwohl die Norm das nicht verlangt [1]. Für den Leser einer Cookie-Liste ist der Wert meist eine Zeichenfolge ohne erkennbare Bedeutung, etwa eine Sitzungskennung. Neben dem Server kann auch ein Skript auf der Seite Cookies anlegen oder ändern [2].

Expires und Max-Age: die Laufzeit

Expires nennt ein festes Datum, Max-Age eine Zahl von Sekunden bis zum Ablauf. Sind beide gesetzt, gilt Max-Age [1, 3]. Ein Wert von null oder kleiner lässt den Cookie sofort verfallen [1]. So löscht ein Server einen Cookie: Er setzt ihn mit gleichem Namen erneut und gibt Max-Age=0 oder ein Datum in der Vergangenheit an [2]. Alle Cookies einer registrierbaren Domain auf einmal entfernt die Kopfzeile Clear-Site-Data mit dem Wert "cookies" [2]. MDN hält Max-Age für weniger fehleranfällig als ein Datum in Expires [2]. Ein Sonderfall sind Antworten auf Anfragen, die ein Skript per fetch() oder XMLHttpRequest über CORS an eine andere Herkunft stellt: Deren Set-Cookie-Zeilen ignoriert der Browser, wenn die Anfrage ohne Anmeldedaten (credentials) gestellt wurde [1]. Weil die Uhr des Servers von der des Browsers abweichen kann, gleichen Firefox und Chromium-Browser die Zeit über die Kopfzeile Date aus [1].

Eine Sanduhr aus Messing steht neben einem Teller mit runden Keksen auf einem Küchentisch
Bild: KI-generiert

Fehlen beide Attribute, entsteht ein Sitzungs-Cookie. Der Browser behält ihn, bis die aktuelle Sitzung endet; was eine Sitzung ist, legt der Browser selbst fest [3]. Viele Browser stellen beim nächsten Start alle Tabs wieder her und mit ihnen die Sitzungs-Cookies, als wäre der Browser nie geschlossen worden [1].

Nach oben hat Chrome die Laufzeit gedeckelt. Seit Chrome 104, erschienen im August 2022, kann ein Cookie höchstens 400 Tage in die Zukunft gelten. Wer einen längeren Zeitraum angibt, bekommt keinen Fehler; der Browser setzt das Ablaufdatum auf 400 Tage nach dem Setzen [4]. Die Grenze stammt aus dem Entwurf für die Nachfolgefassung der Cookie-Norm (rfc6265bis) [4]. Ein Anbieter kann den Cookie bei einem späteren Besuch neu setzen und so verlängern [4].

Ohne Domain-Attribut ist der Cookie ein reiner Host-Cookie und geht nur an den Rechnernamen zurück, der ihn gesetzt hat. Mit Domain-Attribut gilt er für die genannte Domain und alle ihre Subdomains [1]. Die Angabe muss die eigene Domain des Servers oder eine übergeordnete sein. Eine öffentliche Endung wie com, co.uk oder github.io ist nicht erlaubt; solche Cookies verwirft der Browser [1]. Ein Punkt am Anfang, etwa ".example.com", wird ignoriert, und mehrere Domains in einem Attribut sind nicht erlaubt [1]. Wie Subdomains aufgebaut sind, erklärt Was ist eine Subdomain?.

Path grenzt den Cookie auf einen Teil der Website ein. Mit Path=/docs geht der Cookie an /docs, /docs/ und /docs/Web/, nicht aber an / oder /docsets [1]. Fehlt die Angabe, gilt der Pfad der Adresse, die den Cookie gesetzt hat [1]. Als Sicherheitsgrenze taugen beide Attribute nicht. MDN weist ausdrücklich darauf hin, dass Path kein Schutzmechanismus ist [1]. RFC 6265 ergänzt, dass Cookies nicht nach Ports getrennt werden und dass Subdomains auf derselben Ebene Cookies für die gemeinsame übergeordnete Domain setzen können [3].

Secure: nur über HTTPS

Ein Cookie mit Secure geht nur bei Anfragen über https an den Server; eine Ausnahme gilt für localhost [1]. Seiten, die über http geladen werden, dürfen keine Cookies mit Secure setzen [1]. Das Attribut schützt nur die Vertraulichkeit auf dem Übertragungsweg. Ein aktiver Angreifer im Netz kann Secure-Cookies nach RFC 6265 trotzdem über eine unsichere Verbindung überschreiben [3]. Auch auf dem Gerät gespeicherte Daten schützt Secure nicht [2]. Ohne gültiges Zertifikat gibt es kein HTTPS; wie eine Website umstellt, steht unter Von HTTP auf HTTPS umstellen.

Eine kleine verschlossene Stahlkassette auf einem Schreibtisch neben einem Stapel schlichter Briefumschläge
Bild: KI-generiert

HttpOnly: kein Zugriff für Skripte

HttpOnly verbietet JavaScript den Zugriff auf den Cookie, etwa über document.cookie [1]. Der Browser schickt ihn trotzdem bei Anfragen mit, die ein Skript über fetch() oder XMLHttpRequest auslöst [1]. Der Zweck: Schleust ein Angreifer über eine Lücke fremden Code in eine Seite ein (Cross-Site-Scripting, XSS), kann dieser Code ein Sitzungs-Cookie mit HttpOnly nicht auslesen. MDN nennt das eine Abschwächung von XSS-Angriffen und empfiehlt HttpOnly für Sitzungs-Cookies [2]. HttpOnly und Secure sind unabhängig voneinander, ein Cookie kann beide tragen [3]. Für Anmeldungen rät MDN außerdem, das Sitzungs-Cookie nach erfolgreicher Anmeldung neu zu erzeugen und neu zu senden. Das erschwert die sogenannte Session Fixation, bei der ein Angreifer seinem Opfer eine ihm bekannte Sitzungskennung unterschiebt [2].

SameSite: Schutz bei Anfragen von fremden Websites

SameSite bestimmt, ob ein Cookie mitgeht, wenn die Anfrage von einer anderen Website ausgelöst wird. Als "Website" gilt dabei die registrierbare Domain: www.web.dev gehört zur Website web.dev, während zwei Projekte unter github.io getrennte Websites sind [5]. Es gibt drei Werte [1]:

Zwei Gartentore in einer niedrigen Hecke, eines offen, eines geschlossen, dazu zwei Kieswege
Bild: KI-generiert
WertWann der Cookie mitgeht
StrictNur bei Anfragen, die von derselben Website ausgehen.
LaxBei Anfragen derselben Website und zusätzlich, wenn du von einer fremden Website per Link oder Formular auf die Seite wechselst, sofern die Methode sicher ist (kein POST, PUT oder DELETE). Bei eingebundenen Bildern, Skripten, iframes und fetch() von fremden Seiten bleibt er zurück.
NoneBei allen Anfragen, auch von fremden Websites. Der Cookie muss dann zusätzlich Secure tragen.

Strict passt zu besonders heiklen Vorgängen wie dem Ändern eines Passworts oder einem Kauf. Für eine Anzeigeeinstellung ist es zu streng, weil der Cookie fehlt, wenn du über einen Link von einer anderen Website kommst [5]. MDN sieht in SameSite einen gewissen Schutz gegen Cross-Site Request Forgery (CSRF), also Anfragen, die eine fremde Seite in deinem Namen auslöst [2]. Cookies mit SameSite=None ohne Secure nehmen die Browser nicht an [5].

Lax als Standard in Chrome

Fehlt SameSite, behandelt Chrome den Cookie seit 2020 wie SameSite=Lax. Chrome 80 erschien am 04.02.2020. Die neue Regel wurde ab der Woche des 17.02.2020 schrittweise eingeschaltet, am 03.04.2020 wegen der Corona-Pandemie zurückgenommen und ab dem 14.07.2020 erneut verteilt. Ab dem 11.08.2020 sollte sie alle Nutzer von Chrome 80 und neuer erreichen [6]. Eine Übergangsregel lässt Cookies ohne SameSite noch bei POST-Anfragen fremder Seiten mitgehen, wenn sie höchstens zwei Minuten alt sind [6]. Andere Browser verhalten sich ohne SameSite nicht einheitlich, deshalb rät MDN, das Attribut immer ausdrücklich zu setzen und Lax als Grundeinstellung zu wählen [7].

Partitioned und Präfixe im Namen

Das Attribut Partitioned legt einen Cookie in einem getrennten Speicher je Website ab, auf der er eingebunden ist. Das Verfahren heißt CHIPS und setzt ebenfalls Secure voraus. MDN empfiehlt für solche Cookies das Präfix __Host- oder __Host-Http- [1]. Wofür das gut ist, erklärt Drittanbieter-Cookies und Tracking.

Präfixe am Anfang des Namens erzwingen bestimmte Attribute. Der Browser nimmt den Cookie nur an, wenn die Bedingungen erfüllt sind [1]:

  • __Secure-: muss mit Secure von einer HTTPS-Seite gesetzt werden.
  • __Host-: zusätzlich ohne Domain-Attribut und mit Path=/, der Cookie bleibt damit an genau einem Rechnernamen.
  • __Http-: mit Secure und HttpOnly; Skripte können ihn weder setzen noch ändern.
  • __Host-Http-: verbindet die Bedingungen von __Host- und __Http-.

Browser, die Präfixe nicht kennen, akzeptieren solche Cookies ohne die zusätzlichen Prüfungen [1]. Ein Server, der sich auf ein Präfix verlässt, muss deshalb den vollständigen Namen mit Präfix prüfen [2].

Der Cookie-Checker listet für jeden Cookie Name, Wert, Domain, Pfad, Ablaufdatum, Secure und HttpOnly. Ein "Session" beim Ablaufdatum steht für einen Sitzungs-Cookie. In Chrome findest du dieselben Angaben in den Entwicklerwerkzeugen unter Application, Storage und Cookies, dort mit weiteren Spalten wie Size, SameSite, Partition Key und Priority [8]. Was die Laufzeit für die rechtliche Einordnung bedeutet, steht unter Technisch notwendige Cookies. Wie Cookies grundsätzlich funktionieren, erklärt Was Cookies sind und wie sie funktionieren.

  1. Organisation Set-Cookie header. MDN Web Docs (Mozilla). Stand 01.09.2026. abgerufen am 29.10.2026
  2. Organisation Using HTTP cookies. MDN Web Docs (Mozilla). Stand 17.09.2026. abgerufen am 29.10.2026
  3. Gesetz RFC 6265: HTTP State Management Mechanism. Internet Engineering Task Force (IETF), A. Barth. Stand April 2011. abgerufen am 29.10.2026
  4. Organisation Cookie Expires and Max-Age attributes now have upper limit. Google, Chrome for Developers. Stand 12.01.2023. abgerufen am 29.10.2026
  5. Organisation SameSite cookies explained (Rowan Merewood). Google, web.dev. Stand 07.05.2019. abgerufen am 29.10.2026
  6. Organisation SameSite Updates. The Chromium Projects. Stand ohne Datum. abgerufen am 29.10.2026
  7. Organisation Third-party cookies. MDN Web Docs (Mozilla). Stand 15.06.2026. abgerufen am 29.10.2026
  8. Organisation View, add, edit, and delete cookies (Chrome DevTools). Google, Chrome for Developers. Stand 05.12.2023. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.

Weitere Artikel