Set-Cookie

<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, 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 doppelte Anführungszeichen gesetzt werden und beliebige US-ASCII-Zeichen enthalten, ausgenommen Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127), Leerzeichen, Doppelpunkte, Kommas, Semikolons und Backslashes.

Kodierung: Viele Implementierungen führen Prozent-Kodierung für Cookie-Werte durch. Dies ist jedoch nicht durch die RFC-Spezifikation vorgeschrieben. Die Prozent-Kodierung hilft jedoch, die Anforderungen an die 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 (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, es darf keine Domain angegeben sein 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 höherwertige Domain, es sei denn, es handelt sich um ein öffentliches Suffix. Bei Setzen der Domain wird das Cookie sowohl für diese als auch für alle ihre Subdomains verfügbar sein.

Wird dies weggelassen, lautet der Standardwert dieses Attributs der Host der aktuellen Dokument-URL, ausgenommen Subdomains.

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

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

Expires=<date> Optional

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

Wenn nichts angegeben ist, 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 Tabs speichert und beim nächsten Gebrauch des Browsers wiederherstellt. Sitzungs-Cookies werden ebenfalls wiederhergestellt, als ob der Browser nie geschlossen worden wäre.

Das Expires-Attribut wird vom Server mit einem relativen Wert zu seiner internen Uhrzeit 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 Zeitverschiebung auszugleichen, wobei Cookies basierend auf der vom Server beabsichtigten Zeit gespeichert und abgelaufen werden. Die Anpassung an die Uhrzeitverschiebung wird aus dem Wert des DATE-Headers berechnet. Beachten Sie, dass die Spezifikation erklärt, wie das Attribut geparst werden sollte, jedoch nicht angibt, ob/wie der Wert vom Empfänger korrigiert werden soll.

HttpOnly Optional

Verbietet JavaScript, auf das Cookie zuzugreifen, beispielsweise über die Document.cookie-Eigenschaft. Beachten Sie, dass ein Cookie, das mit HttpOnly erstellt wurde, dennoch mit JavaScript-initiierten Anfragen gesendet wird, z. B. bei einem Aufruf von XMLHttpRequest.send() oder fetch(). Dies mildert Angriffe gegen Cross-Site-Scripting (XSS).

Max-Age=<number> Optional

Gibt die Anzahl der Sekunden bis zum Ablauf des Cookies an. 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 mit partitioniertem Speicher gespeichert werden soll. Beachten Sie, dass, wenn dies gesetzt ist, die Secure-Direktive ebenfalls gesetzt sein muss. Siehe Cookies Having Independent Partitioned State (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.

Das Schrägstrich-Zeichen (/) wird als Verzeichnistrenner interpretiert, und Unterverzeichnisse werden ebenfalls abgeglichen. Zum Beispiel wird bei Path=/docs,

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

SameSite=<samesite-value> Optional

Kontrolliert, ob ein Cookie mit standortübergreifenden Anfragen gesendet wird oder nicht: d.h. Anfragen, die von einer anderen Website einschließlich des Schemas stammen, als die Website, die das Cookie gesetzt hat. Dies bietet einen gewissen Schutz gegen bestimmte standortübergreifende Angriffe, einschließlich Cross-Site-Request-Forgery-(CSRF)-Angriffen.

Die möglichen Attributwerte sind:

Strict

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

Lax

Sendet das Cookie nur für Anfragen, die von derselben Website stammen, die das Cookie gesetzt hat, und für standortübergreifende Anfragen, die beide der folgenden Kriterien erfüllen:

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

  • Dies würde zum Beispiel Anfragen ausschließen, die mithilfe des fetch()-API gemacht werden, oder Anfragen, die aus <img>- oder <script>-Elementen stammen, oder Navigierungen innerhalb von <iframe>-Elementen.

  • Dies würde Anfragen einschließen, die gemacht werden, wenn der Benutzer im Top-Level-Browsing-Kontext von einer Website zu einer anderen auf einen Link klickt, oder eine Zuweisung zu document.location, oder eine <form>-Einreichung.

• 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 weniger restriktive Version verwendet. In dieser weniger restriktiven Version werden Cookies auch in POST-Anfragen eingeschlossen, solange sie nicht mehr als zwei Minuten vor der Anfrage gesetzt wurden.

None

Sendet das Cookie sowohl mit standortübergreifenden als auch gleichen Standortanfragen. Das Secure-Attribut muss auch gesetzt werden, wenn dieser Wert verwendet wird.

Secure Optional

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

Hinweis: Gehen Sie nicht davon aus, dass Secure jeglichen Zugang zu sensiblen Informationen in Cookies (Sitzungsschlüssel, Login-Daten etc.) verhindert. Cookies mit diesem Attribut können weiterhin entweder durch Zugriff auf die Festplatte des Clients oder durch JavaScript gelesen/verändert werden, wenn das HttpOnly-Cookie-Attribut nicht gesetzt ist.

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

Sitzungs-Cookies werden entfernt, wenn der Client heruntergefahren wird. Cookies sind Sitzungs-Cookies, 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) 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

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 dienenden 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 mit dem Präfix __Secure- oder __Host- dürfen nur verwendet werden, wenn sie mit dem secure-Attribut von einem sicheren (HTTPS) Ursprung gesetzt werden.

Darüber hinaus müssen Cookies mit dem __Host--Präfix einen Pfad von / haben (was 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)