Set-Cookie header

Syntax

Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
Set-Cookie: <cookie-name>=<cookie-value>; Partitioned
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure

// Multiple attributes are also possible, for example:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

Attribute

<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, Tabulator und die Zeichen: ( ) < > @ , ; : \ " / [ ] ? = { })

Ein <cookie-value> kann optional in Anführungszeichen eingeschlossen werden und beliebige US-ASCII-Zeichen enthalten, ausgenommen Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127), Leerzeichen, Anführungszeichen, Kommas, Semikolons und Backslashes.

Codierung: Viele Implementierungen führen Prozentcodierung bei Cookie-Werten durch. Dies ist jedoch nicht durch die RFC-Spezifikationen vorgeschrieben. Die Prozentcodierung hilft jedoch dabei, die Anforderungen an die für <cookie-value> erlaubten Zeichen zu erfüllen.

Hinweis: Einige Cookie-Namen enthalten Präfixe, die spezifische Einschränkungen hinsichtlich der Attribute des Cookies bei unterstützenden Benutzeragenten auferlegen. Siehe Cookie-Präfixe für weitere Informationen.

Domain=<domain-value> Optional

Legt fest, an welche Hosts das Cookie gesendet wird.

Die Festlegung der Domain macht das Cookie für diese Domain und alle ihre Subdomains verfügbar. Wenn sie weggelassen wird, wird das Cookie nur an den Host zurückgesendet, der es gesendet hat (d.h. es wird zu einem "Host-only Cookie"). Dies ist restriktiver als die Angabe des Hostnamens, da das Cookie nicht für Subdomains des Hosts verfügbar gemacht wird.

Der Wert muss die Domain des Servers sein, der den Set-Cookie-Antwort-Header sendet, oder eine übergeordnete Domain dieser Serverdomain. Sie kann kein public suffix wie com, co.uk oder github.io sein. Ein Beispiel: Eine Antwort von api.example.com kann Domain=api.example.com oder Domain=example.com setzen, aber nicht Domain=beta.api.example.com, Domain=other.example.com oder Domain=com. Ebenso kann eine Antwort von shop.example.co.uk Domain=shop.example.co.uk oder Domain=example.co.uk setzen, aber nicht Domain=co.uk, da co.uk ein Public Suffix ist. Cookies, die gegen diese Regeln verstoßen, werden ignoriert.

Entgegen früherer Spezifikationen werden führende Punkte in Domainnamen (.example.com) ignoriert.

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

Expires=<date> Optional

Gibt die maximale Lebensdauer des Cookies als HTTP-Datumstempel 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, danach wird das Session-Cookie entfernt.

Warnung: Viele Webbrowser haben eine Sitzungswiederherstellungs -Funktion, die alle Registerkarten speichert und beim nächsten Verwenden des Browsers wiederherstellt. Sitzungs-Cookies werden ebenfalls wiederhergestellt, als ob der Browser nie geschlossen wurde.

Das Expires-Attribut wird vom Server mit einem Wert relativ zu seiner eigenen internen Uhr gesetzt, die sich von der des Client-Browsers unterscheiden kann. Firefox und auf Chromium basierende Browser verwenden intern einen Verfallswert (Max-Age), der angepasst wird, um die Uhrzeitdifferenz zu kompensieren, wobei Cookies basierend auf der vom Server beabsichtigten Zeit gespeichert und abgelaufen sind. Der Abgleich für die Uhrenabweichung wird aus dem Wert 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

Verhindert, dass JavaScript auf das Cookie zugreift, 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 mindert 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 lassen das Cookie sofort ablaufen. Wenn Expires und Max-Age beide gesetzt sind, hat Max-Age Vorrang.

Partitioned Optional

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

Path=<path-value> Optional

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

Wenn weggelassen, wird dieses Attribut standardmäßig auf den Pfadkomponenten der Anforderungs-URL gesetzt. Wenn ein Cookie zum Beispiel durch eine Anfrage an https://example.com/docs/Web/HTTP/index.html gesetzt wird, lautet der Standardpfad /docs/Web/HTTP/.

Der Schrägstrich (/) wird als Verzeichnis-Trennzeichen interpretiert und auch Unterverzeichnisse werden abgeglichen. Zum Beispiel für Path=/docs,

• werden die Anforderungspfade /docs, /docs/, /docs/Web/ und /docs/Web/HTTP alle abgeglichen.
• die Anforderungspfade /, /docsets, /fr/docs werden nicht abgeglichen.

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 gegen unbefugtes 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, von 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

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

Lax

Sendet 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 Top-Level-Navigation: Dies bedeutet im Wesentlichen, dass die Anfrage bewirkt, dass sich die in der Adressleiste des Browsers gezeigte URL ändert.

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

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

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

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

Hinweis: Wenn Lax als Standard angewendet wird, wird eine permissivere Version verwendet. In dieser permissiveren Version werden Cookies auch in POST-Anfragen einbezogen, solange sie nicht mehr 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 auch gesetzt werden, wenn dieser Wert verwendet wird.

Secure Optional

Gibt an, dass das Cookie nur gesendet wird, wenn eine Anfrage mit dem https:-Schema gemacht wird (außer auf localhost) und daher widerstandsfähiger gegen Man-in-the-Middle (MITM) Angriffe ist.

Hinweis: Gehen Sie nicht davon aus, dass Secure jeglichen Zugriff auf sensible Informationen in Cookies (Sitzungsschlüssel, Anmeldedaten, etc.) verhindert. Cookies mit diesem Attribut können dennoch entweder über den Zugriff auf die Festplatte des Clients oder von JavaScript gelesen/geändert werden, 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 wird.

Cookies-Präfixe

Einige Cookies-Namen enthalten Präfixe, die spezifische Einschränkungen hinsichtlich der Attribute des Cookies bei unterstützenden Benutzeragenten auferlegen. Alle Cookie-Präfixe beginnen mit einem doppelten Unterstrich (__) und enden mit einem Bindestrich (-). Die folgenden Präfixe sind definiert:

• __Secure-: Cookies mit Namen, die mit __Secure- beginnen, müssen mit dem Secure-Attribut von einer sicheren Seite (HTTPS) gesetzt werden.
• __Host-: Cookies mit Namen, die mit __Host- beginnen, müssen mit dem Secure-Attribut von einer sicheren Seite (HTTPS) gesetzt werden. Zusätzlich dürfen sie kein Domain-Attribut spezifiziert haben und das Path-Attribut muss auf / gesetzt werden. Dies garantiert, dass solche Cookies nur an den Host gesendet werden, der sie gesetzt hat, und nicht an einen anderen Host auf der Domain. Es garantiert auch, dass sie hostweit gesetzt und nicht auf einem beliebigen Pfad auf diesem Host überschrieben werden können. Diese Kombination führt zu einem Cookie, das so nah wie möglich kommt, die Herkunft als Sicherheitsgrenze zu behandeln.
• __Http-: Cookies mit Namen, die mit __Http- beginnen, müssen mit dem Secure-Flag von einer sicheren Seite (HTTPS) gesetzt werden und zusätzlich das HttpOnly-Attribut gesetzt haben, um zu beweisen, dass sie über den Set-Cookie-Header gesetzt wurden (sie können nicht über JavaScript-Funktionen wie Document.cookie oder die Cookie Store API gesetzt oder geändert werden).
• __Host-Http-: Cookies mit Namen, die mit __Host-Http- beginnen, müssen mit dem Secure-Flag von einer sicheren Seite (HTTPS) gesetzt und das HttpOnly-Attribut gesetzt haben, um zu beweisen, dass sie über den Set-Cookie-Header gesetzt wurden. Zusätzlich haben sie die gleichen Einschränkungen wie mit __Host--präfixierten Cookies. Diese Kombination führt zu einem Cookie, das so nah wie möglich kommt, die Herkunft als Sicherheitsgrenze zu behandeln, während gleichzeitig sichergestellt wird, dass Entwickler und Serverbetreiber wissen, dass sein Anwendungsbereich auf HTTP-Anfragen beschränkt ist.

Beispiele

Sitzungscookie

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

Set-Cookie: sessionId=38afes7a8

Permanentes Cookie

Permanente Cookies werden zu einem bestimmten Datum (Expires) oder nach einer bestimmten Zeitspanne (Max-Age) und nicht beim Schließen des Clients entfernt.

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

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

Ungültige Domains

Ein Cookie für eine Domain, die nicht den Server einschließt, der es gesetzt hat, sollte vom Benutzeragenten 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 bedienenden 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-Präfixe

Cookie-Namen mit dem Präfix __Secure- oder __Host- können nur verwendet werden, wenn sie mit dem Secure-Attribut von einem sicheren (HTTPS) Ursprung gesetzt werden.

Cookie-Namen mit dem Präfix __Http- oder __Host-Http- können nur verwendet werden, wenn sie mit dem Secure-Attribut von einem sicheren (HTTPS) Ursprung gesetzt werden und zusätzlich das HttpOnly-Attribut gesetzt haben, um zu beweisen, dass sie über den Set-Cookie-Header und nicht clientseitig über JavaScript gesetzt wurden.

Außerdem müssen Cookies mit dem Präfix __Host- oder __Host-Http- einen Pfad von / haben (bedeutet, jeglicher Pfad am 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

// Only settable via Set-Cookie
Set-Cookie: __Http-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-Http-ID=123; Secure; Path=/

Partitionierter Cookie

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Spezifikationen

Browser-Kompatibilität

Siehe auch

• HTTP-Cookies
• Cookie
• Document.cookie
• SameSite-Cookies erklärt (web.dev blog)