Set-Cookie header

<cookie-name>=<cookie-value>

Definiert den Cookie-Namen und seinen Wert. Eine Cookie-Definition beginnt mit einem Name-Wert-Paar.

Ein <cookie-name> kann beliebige US-ASCII-Zeichen enthalten, mit Ausnahme von Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127) oder Trennzeichen (Leerzeichen, Tabulatoren und die Zeichen: ( ) < > @ , ; : \ " / [ ] ? = { }).

Ein <cookie-value> kann optional in Anführungszeichen gesetzt werden und beliebige US-ASCII-Zeichen enthalten, außer Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127), Leerraum, Anführungszeichen, Kommata, Semikolons und Backslashes.

Codierung: Viele Implementierungen führen eine Prozentcodierung der Cookie-Werte durch. Dies ist jedoch nicht durch die RFC-Spezifikation gefordert. Die Prozentcodierung hilft, die Anforderungen der zulässigen Zeichen für <cookie-value> zu erfüllen.

Hinweis: Einige <cookie-name> haben eine spezifische Semantik:

__Secure--Präfix: Cookies mit Namen, die mit __Secure- beginnen (der Bindestrich ist Teil des Präfixes), müssen mit dem secure-Flag von einer sicheren Seite (HTTPS) gesetzt werden.

__Host--Präfix: Cookies mit Namen, die mit __Host- beginnen, werden nur an die Host-Subdomain oder -Domain gesendet, die sie gesetzt hat, und nicht an andere Hosts. Sie müssen mit dem secure-Flag gesetzt werden, müssen von einer sicheren Seite (HTTPS) stammen, dürfen keine Domain angegeben haben und der Pfad muss / sein.

Domain=<domain-value> Optional

Definiert den Host, an den das Cookie gesendet wird.

Nur die aktuelle Domain kann als Wert gesetzt werden, oder eine Domain höheren Rangs, es sei denn, es handelt sich um ein öffentliches Suffix. Das Setzen der Domain macht das Cookie für diese verfügbar sowie für alle ihre Subdomains.

Wenn nicht angegeben, wird dieser Attributstandard auf den Host der aktuellen Dokument-URL gesetzt, ohne Subdomains einzuschließen.

Im Gegensatz zu früheren Spezifikationen werden führende Punkte in Domain-Namen (.example.com) ignoriert.

Mehrfache Host-/Domain-Werte sind nicht erlaubt, aber wenn eine Domain angegeben ist, sind Subdomains immer enthalten.

Expires=<date> Optional

Gibt die maximale Lebensdauer des Cookies als HTTP-Datumstempel an. Siehe Date für die erforderliche Formatierung.

Wenn nicht angegeben, wird das Cookie zu einem Sitzungscookie. Eine Sitzung endet, wenn der Client heruntergefahren wird, woraufhin das Sitzungscookie entfernt wird.

Warnung: Viele Webbrowser haben eine Sitzungswiederherstellungs-Funktion, die alle Tabs speichert und sie beim nächsten Gebrauch des Browsers wiederherstellt. Sitzungscookies werden ebenfalls wiederhergestellt, als ob der Browser nie geschlossen worden wäre.

Das Expires-Attribut wird vom Server mit einem Wert eingestellt, der relativ zu seiner eigenen internen Uhr ist, die von der des Client-Browsers abweichen kann. Firefox und auf Chromium basierende Browser verwenden intern einen Ablaufwert (max-age), der angepasst wird, um die Uhrendifferenz zu kompensieren und speichern und löschen Cookies basierend auf der vom Server beabsichtigten Zeit. Die Anpassung für den Uhrenskew wird aus dem Wert des DATE-Headers berechnet. Beachten Sie, dass die Spezifikation erklärt, wie das Attribut geparst werden sollte, aber nicht, ob/wie der Wert vom Empfänger korrigiert werden sollte.

HttpOnly Optional

Verbietet JavaScript den Zugriff auf das Cookie, zum Beispiel über die Document.cookie-Eigenschaft. Beachten Sie, dass ein Cookie, das mit HttpOnly erstellt wurde, trotzdem mit von JavaScript initiierten Anfragen gesendet wird, beispielsweise beim Aufruf von XMLHttpRequest.send() oder fetch(). Dies mildert Angriffe gegen Cross-Site Scripting (XSS) ab.

Max-Age=<number> Optional

Gibt die Anzahl der Sekunden an, bis das Cookie abläuft. Eine Null oder eine negative Zahl wird das Cookie sofort ablaufen lassen. Wenn sowohl Expires als auch Max-Age gesetzt sind, hat Max-Age Vorrang.

Partitioned Optional

Gibt an, dass das Cookie unter Verwendung von partitioniertem Speicher gespeichert werden soll. Beachten Sie, dass, wenn dies gesetzt ist, die Secure-Direktive ebenfalls gesetzt sein muss. Siehe Cookies mit unabhängiger partitionierter Speicherung (CHIPS) für weitere Details.

Path=<path-value> Optional

Gibt den Pfad an, der existieren muss in der angeforderten URL, damit der Browser den Cookie-Header sendet.

Wenn weggelassen, ist dieser Attributstandard der Pfadteil der Anfrage-URL. Zum Beispiel, wenn ein Cookie durch eine Anfrage auf https://example.com/docs/Web/HTTP/index.html gesetzt wird, wäre der Standardpfad /docs/Web/HTTP/.

Der Schrägstrich (/) wird als Verzeichnisseparator interpretiert, und Unterverzeichnisse werden ebenfalls übereinstimmend. Zum Beispiel, für Path=/docs,

• werden die Anfragepfade /docs, /docs/, /docs/Web/, und /docs/Web/HTTP alle übereinstimmen.
• die Anfragepfade /, /docsets, /fr/docs werden nicht übereinstimmen.

Hinweis: Das path-Attribut ermöglicht es Ihnen, zu steuern, welche Cookies der Browser basierend auf den verschiedenen Teilen einer Seite sendet. Es ist nicht als Sicherheitsmaßnahme gedacht und schützt nicht vor unbefugtem Lesen des Cookies von einem anderen Pfad.

SameSite=<samesite-value> Optional

Steuert, ob ein Cookie mit Cross-Site-Anfragen gesendet wird: das heißt, Anfragen, die von einer anderen Seite stammen, einschließlich des Schemas, als der Seite, die das Cookie gesetzt hat. Dies bietet einen gewissen Schutz gegen bestimmte Cross-Site-Angriffe, einschließlich Cross-Site Request Forgery (CSRF)-Angriffe.

Die möglichen Attributwerte sind:

Strict

Senden Sie das Cookie nur für Anfragen, die von derselben Seite stammen, die das Cookie gesetzt hat.

Lax

Senden Sie das Cookie nur für Anfragen, die von derselben Seite stammen, die das Cookie gesetzt hat, und für Cross-Site-Anfragen, die beide der folgenden Kriterien erfüllen:

• Die Anfrage ist eine Navigation auf oberster Ebene: das bedeutet im Wesentlichen, dass die Anfrage dazu führt, dass sich die URL ändert, die in der Adressleiste des Browsers angezeigt wird.

  • Dies würde beispielsweise Anfragen ausschließen, die über die fetch()-API gemacht werden, oder Anfragen für Subressourcen von <img> oder <script>-Elementen, oder Navigationen innerhalb von <iframe>-Elementen.

  • Sie umfassen Anfragen, die gemacht werden, wenn der Benutzer in der obersten Browsing-Kontext von einer Seite zur anderen auf einen Link klickt, oder eine Zuweisung an document.location, oder eine <form>-Einsendung.

• Die Anfrage verwendet eine sichere Methode: ins besonders, dies schließt POST, PUT, und DELETE aus.

Einige Browser verwenden Lax als Standardwert, wenn SameSite nicht angegeben ist: Siehe Browser-Kompatibilität für Details.

Hinweis: Wenn Lax als Standardwert angewendet wird, wird eine permissivere Version verwendet. In dieser permissiveren Version werden Cookies auch in POST-Anfragen eingeschlossen, sofern sie nicht mehr als zwei Minuten vor der Anfrage gesetzt wurden.

None

Senden Sie das Cookie sowohl mit Cross-Site- als auch mit Same-Site-Anfragen. Das Secure-Attribut muss ebenfalls gesetzt sein, wenn dieser Wert verwendet wird.

Secure Optional

Gibt an, dass das Cookie zum Server nur gesendet wird, wenn eine Anfrage mit dem https:-Schema gemacht wird (außer bei localhost) und daher besser gegen Man-in-the-Middle-Angriffe geschützt ist.

Hinweis: Gehen Sie nicht davon aus, dass Secure alle Zugriffe auf sensible Informationen in Cookies (Sitzungsschlüssel, Login-Details, etc.) verhindert. Cookies mit diesem Attribut können immer noch entweder mit Zugriff auf die Festplatte des Clients gelesen/verändert werden oder von JavaScript, wenn das HttpOnly-Cookie-Attribut nicht gesetzt ist.

Unsichere Seiten (http:) können keine Cookies mit dem Secure-Attribut setzen. Die https:-Anforderungen werden ignoriert, wenn das Secure-Attribut von localhost gesetzt ist.

Sitzungscookies werden entfernt, wenn der Client heruntergefahren wird. Cookies sind Sitzungscookies, wenn sie das Expires- oder Max-Age-Attribut nicht spezifizieren.

Set-Cookie: sessionId=38afes7a8

Permanente Cookies werden an einem bestimmten Datum (Expires) oder nach einer bestimmten Zeitspanne (Max-Age) entfernt und nicht, wenn der Client geschlossen wird.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT

Set-Cookie: id=a3fWa; Max-Age=2592000

Ein Cookie für eine Domain, die nicht den Server enthält, der es gesetzt hat, sollte vom User Agent abgelehnt werden.

Das folgende Cookie wird abgelehnt, wenn es von einem Server auf original-company.com gesetzt wird:

Set-Cookie: qwerty=219ffwef9w0f; Domain=some-company.co.uk

Ein Cookie für eine Subdomain der diensthabenden Domain wird abgelehnt.

Das folgende Cookie wird abgelehnt, wenn es von einem Server auf example.com gesetzt wird:

Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com

Cookie-Namen, die mit __Secure- oder __Host- beginnen, können nur verwendet werden, wenn sie mit dem secure-Attribut von einem sicheren (HTTPS) Ursprung gesetzt werden.

Zudem müssen Cookies mit dem __Host--Präfix einen Pfad von / haben (bedeutet, dass jeder Pfad beim Host ist) und dürfen kein Domain-Attribut haben.

// Both accepted when from a secure origin (HTTPS)
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-ID=123; Secure; Path=/

// Rejected due to missing Secure attribute
Set-Cookie: __Secure-id=1

// Rejected due to the missing Path=/ attribute
Set-Cookie: __Host-id=1; Secure

// Rejected due to setting a Domain
Set-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com

• HTTP-Cookies
• Cookie
• Document.cookie
• Samesite-Cookies erklärt (web.dev Blog)