Set-Cookie header

<cookie-name>=<cookie-value>

Definiert den Namen des Cookies und seinen Wert. Die Definition eines Cookies beginnt mit einem Namen-Wert-Paar.

Ein <cookie-name> kann alle 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 gesetzt werden und darf alle US-ASCII-Zeichen enthalten, mit Ausnahme von Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127), Leerzeichen, Anführungszeichen, Kommas, Semikola und Rückschrägstrichen.

Codierung: Viele Implementierungen führen eine Prozent-Codierung der Cookie-Werte durch. Dies ist jedoch nicht durch die RFC-Spezifikation vorgeschrieben. Die Prozent-Codierung hilft jedoch, die Anforderungen der erlaubten 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 gehört zum Präfix), 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 oder eine höher geordnete Domain kann als Wert gesetzt werden, es sei denn, es ist ein öffentlicher Suffix. Das Setzen der Domain macht das Cookie sowohl für diese als auch für alle ihre Subdomains verfügbar.

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

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

Mehrere Host- oder Domainwerte sind nicht erlaubt, aber wenn eine Domain angegeben ist, sind Subdomains immer eingeschlossen.

Expires=<date> Optional

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

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

Warnung: Viele Webbrowser verfügen über eine Sitzungswiederherstellungs-Funktion, die alle Tabs speichert und das nächste Mal wiederherstellt, wenn der Browser verwendet wird. Sitzungscookies werden ebenfalls wiederhergestellt, als ob der Browser nie geschlossen worden wäre.

Das Expires-Attribut wird vom Server mit einem Wert relativ zu seiner eigenen internen Uhrzeit gesetzt, die von der des Client-Browsers abweichen kann. Firefox und Chromium-basierte Browser verwenden intern einen Ablaufwert (max-age), der angepasst wird, um Uhrzeitunterschiede auszugleichen, wobei Cookies basierend auf der vom Server beabsichtigten Zeit gespeichert und ablaufen. Die Anpassung für Abweichung der Uhrzeit wird aus dem Wert des DATE-Headers berechnet. Beachten Sie, dass die Spezifikation erklärt, wie das Attribut geparst werden soll, aber nicht angibt, ob/wie der Wert von der empfangenden Seite korrigiert werden soll.

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, weiterhin mit JavaScript-initiierten Anfragen gesendet wird, z. B. bei einem Aufruf 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 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. Weitere Details finden Sie unter Cookies mit unabhängigem partitioniertem Zustand (CHIPS).

Path=<path-value> Optional

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

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

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

Hinweis: Das path-Attribut ermöglicht Ihnen die Kontrolle darüber, 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 oder nicht: das heißt, Anfragen, die von einer anderen Site als der stammen, die das Cookie gesetzt hat, einschließlich des Schemas. Dies bietet einen gewissen Schutz gegen bestimmte Cross-Site-Angriffe, einschließlich Cross-Site-Request-Forgery (CSRF)-Angriffe.

Die möglichen Attributwerte sind:

Strict

Sende das Cookie nur für Anfragen, die von derselben Site stammen, die das Cookie gesetzt hat.

Lax

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

• Die Anfrage ist eine Top-Level-Navigation: das bedeutet im Wesentlichen, dass die Anfrage die URL ändert, die in der Adressleiste des Browsers angezeigt wird.

  • Dies würde beispielsweise Anfragen ausschließen, die unter Verwendung der fetch()-API oder Anfragen nach Subressourcen von <img>- oder <script>-Elementen gemacht werden, oder Navigationen in <iframe>-Elementen.

  • Dazu gehören Anfragen, die gemacht werden, wenn der Benutzer auf einen Link im Top-Level-Browsing-Kontext von einer Seite zur anderen klickt, oder eine Zuweisung zu document.location, oder ein <form>-Versand.

• Die Anfrage verwendet eine sichere Methode: insbesondere 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 eingeschlossen, solange sie nicht mehr als zwei Minuten vor der Anfrage gesetzt wurden.

None

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

Secure Optional

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

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

Set-Cookie: sessionId=38afes7a8

Permanente Cookies werden zu 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 den Server, der es gesetzt hat, nicht einschließt, 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 servierenden 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

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

Zusätzlich müssen Cookies mit dem __Host--Präfix einen Pfad von / haben (was bedeutet, dass jeder Pfad beim Host gemeint 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)