Set-Cookie header

<cookie-name>=<cookie-value>

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

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

Ein <cookie-value> kann optional in Anführungszeichen eingebettet sein und jedes US-ASCII-Zeichen außer Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127), Whitespace, Anführungszeichen, Kommata, Semikolons und Rückwärtsschrägstrich enthalten.

Encoding: Viele Implementierungen führen eine Prozent-Codierung von Cookie-Werten durch. Dies ist jedoch nicht durch die RFC-Spezifikation vorgeschrieben. Die Prozent-Codierung hilft, die Anforderungen der für <cookie-value> zulässigen Zeichen 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) aus 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 spezifiziert 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 einer höheren Ordnung, es sei denn, es ist ein öffentlicher Suffix. Durch das Setzen der Domain wird das Cookie sowohl für diese als auch für alle ihre Subdomains verfügbar gemacht.

Wenn es weggelassen wird, wird dieses Attribut standardmäßig auf den Host der aktuellen Dokument-URL ohne Subdomains gesetzt.

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

Mehrere 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-Datum-Zeitstempel an. Siehe Date für das erforderliche Format.

Wenn nicht angegeben, wird das Cookie zu einem Session-Cookie. Eine Sitzung endet, wenn der Client heruntergefahren wird, wonach das Session-Cookie entfernt wird.

Warnung: Viele Webbrowser haben eine Sitzungswiederherstellungs-Funktion, die alle Tabs speichert und das nächste Mal, wenn der Browser verwendet wird, wiederherstellt. Sitzungs-Cookies werden ebenfalls wiederhergestellt, als wäre der Browser nie geschlossen worden.

Das Expires-Attribut wird vom Server mit einem Wert relativ zu seiner eigenen internen Uhr gesetzt, die von der des Client-Browsers abweichen kann. Firefox und Chromium-basierte Browser verwenden intern einen Ablaufwert (max-age), der zur Kompensation für Uhrendrift angepasst ist, um Cookies zu speichern und ablaufen zu lassen, basierend auf der vom Server beabsichtigten Zeit. Die Anpassung für Uhrendrift wird anhand des Werts des DATE-Headers berechnet. Beachten Sie, dass die Spezifikation erklärt, wie das Attribut geparst werden sollte, aber nicht angibt, ob/wie der Wert vom Empfänger korrigiert werden sollte.

HttpOnly Optional

Verbietet JavaScript, auf das Cookie zuzugreifen, zum Beispiel über die Document.cookie-Eigenschaft. Beachten Sie, dass ein Cookie, das mit HttpOnly erstellt wurde, dennoch mit von JavaScript initiierten Anfragen gesendet wird, zum Beispiel beim Aufrufen von XMLHttpRequest.send() oder fetch(). Dies vermindert Angriffe gegen Cross-Site-Scripting (XSS).

Max-Age=<number> Optional

Gibt die Anzahl der Sekunden an, bis das Cookie abläuft. Eine Null oder eine negative Zahl lässt das Cookie sofort ablaufen. 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 sollte. Beachten Sie, dass, wenn dies gesetzt ist, auch die Secure-Direktive gesetzt sein muss. Siehe Cookies mit unabhängigem partitionierten Status (CHIPS) für weitere Details.

Path=<path-value> Optional

Gibt den Pfad an, der im angeforderten URL vorhanden sein muss, damit der Browser den Cookie-Header sendet.

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

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

Hinweis: Das path-Attribut lässt Sie 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

Bestimmt, ob ein Cookie bei Cross-Site-Anfragen gesendet wird: das heißt, Anfragen, die von einer anderen Site stammen, einschließlich des Schemas, als von der Site, 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 Attributswerte sind:

Strict

Sendet das Cookie nur für Anfragen, die von der gleichen Site stammen, die das Cookie gesetzt hat.

Lax

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

• Die Anfrage ist eine Top-Level-Navigation: das bedeutet im Wesentlichen, dass die Anfrage dazu führt, dass die in der Adressleiste des Browsers angezeigte URL geändert wird.

  • Dies würde zum Beispiel Anfragen ausschließen, die mit der fetch()-API gemacht wurden, oder Anfragen für Unterressourcen von <img> oder <script>-Elementen oder Navigierungen innerhalb von <iframe>-Elementen.

  • Es würde Anfragen einschließen, die gemacht werden, wenn der Benutzer in einem Top-Level-Browsing-Kontext von einer Seite zur anderen klickt, oder eine Zuweisung zu document.location macht, oder ein <form>-Einsendung.

• Die Anfrage verwendet eine sichere Methode: insbesonders schließt dies 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 Standard angewendet wird, wird eine freizügigere Version verwendet. In dieser freizügigeren Version werden Cookies auch in POST-Anfragen einbezogen, solange sie nicht länger als zwei Minuten vor der Anfrage gesetzt wurden.

None

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

Secure Optional

Zeigt an, dass das Cookie nur dann an den Server gesendet wird, wenn eine Anfrage mit dem https:-Schema erfolgt (außer auf localhost), und daher resistenter gegen Man-in-the-Middle-Angriffe ist.

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

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

Sitzungscookies werden entfernt, wenn der Client heruntergefahren wird. Cookies sind Sitzungscookies, wenn sie kein Expires- oder Max-Age-Attribut angeben.

Set-Cookie: sessionId=38afes7a8

Permanente Cookies werden zu einem bestimmten Datum (Expires) oder nach einer bestimmten Zeitdauer (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 den Server, der es gesetzt hat, nicht einschließt, sollte vom Benutzer-Agenten abgelehnt werden.

Das folgende Cookie wird abgelehnt, wenn es von einem Server gehostet 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 gehostet auf example.com gesetzt wird:

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

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

Zusätzlich müssen Cookies mit dem __Host- Präfix einen Pfad von / haben (d.h. jeden Pfad beim Host) 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)