Set-Cookie

<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 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 sein und jedes US-ASCII-Zeichen enthalten, mit Ausnahme von Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127), Whitespace, Anführungszeichen, Kommata, Semikolons und Backslashes.

Kodierung: Viele Implementierungen führen prozentuale Kodierung auf Cookie-Werten durch. Dies ist jedoch nicht durch die RFC-Spezifikation vorgeschrieben. Die prozentuale Kodierung hilft, die Anforderungen an die für <cookie-value> erlaubten 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) 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 festgelegt werden, oder eine höher geordnete Domain, außer es handelt sich um ein öffentliches Suffix. Das Festlegen der Domain macht das Cookie darin verfügbar sowie für alle ihre Subdomains.

Wenn dieser Parameter weggelassen wird, lautet der Standardwert dieses Attributs der Host der aktuellen Dokument-URL, ohne Subdomains.

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

Mehrere Host-/Domain-Werte sind nicht erlaubt, aber wenn eine Domain angegeben ist, werden Subdomains immer einbezogen.

Expires=<date> Optional

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

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

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

Wenn ein Expires-Datum gesetzt ist, ist die Frist relativ zum Client, auf dem das Cookie gesetzt wird, nicht zum Server.

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, dennoch mit durch JavaScript initiierte Anfragen gesendet wird, zum Beispiel beim Aufruf von XMLHttpRequest.send() oder fetch(). Dies verringert die Gefahr von Cross-Site-Scripting-Angriffen (XSS).

Max-Age=<number> Optional

Gibt die Anzahl der Sekunden an, bis das Cookie abläuft. Eine Null oder eine negative Zahl führt dazu, dass das Cookie sofort abläuft. 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, 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 im angeforderten URL vorhanden sein muss, damit der Browser den Cookie-Header sendet.

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

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

SameSite=<samesite-value> Optional

Kontrolliert, ob ein Cookie mit anfragen über Domänengrenzen hinweg gesendet wird oder nicht und bietet einen gewissen Schutz gegen Cross-Site-Request-Fälschung-Angriffe (CSRF).

Die möglichen Attributwerte sind:

Strict

Bedeutet, dass der Browser das Cookie nur für gleichseitige Anfragen sendet, das heißt, Anfragen, die von derselben Site stammen, die das Cookie gesetzt hat. Wenn eine Anfrage von einer anderen Domain oder einem anderen Schema ausgeht (auch bei derselben Domain), werden keine Cookies mit dem SameSite=Strict-Attribut gesendet.

Lax

Bedeutet, dass das Cookie nicht bei anfragen über Domänengrenzen hinweg gesendet wird, wie etwa bei Anforderungen zum Laden von Bildern oder Frames, jedoch bei Navigieren eines Benutzers zur Ursprungs-Site von einer externen Site gesendet wird (zum Beispiel beim Verfolgen eines Links). Dies ist das Standardverhalten, wenn das SameSite-Attribut nicht angegeben ist.

Warnung: Nicht alle Browser setzen SameSite=Lax standardmäßig. Weitere Informationen finden Sie unter Browser-Kompatibilität.

None

Bedeutet, dass der Browser das Cookie sowohl mit anfragen über Domänengrenzen hinweg als auch mit gleichseitigen Anfragen sendet. Das Secure-Attribut muss auch gesetzt werden, wenn dieser Wert gesetzt ist, also SameSite=None; Secure. Wenn Secure fehlt, wird ein Fehler protokolliert:

Cookie "myCookie" rejected because it has the "SameSite=None" attribute but is missing the "secure" attribute.

This Set-Cookie was blocked because it had the "SameSite=None" attribute but did not have the "Secure" attribute, which is required in order to use "SameSite=None".

Hinweis: Ein Secure-Cookie wird nur mit einer verschlüsselten Anfrage über das HTTPS-Protokoll an den Server gesendet. Es ist zu beachten, dass unsichere Seiten (http:) keine Cookies mit der Secure-Direktive setzen können und daher SameSite=None nicht verwenden können.

Warnung: Cookies mit SameSite=None; Secure, die nicht auch das Partitioned-Attribut haben, können in zukünftigen Browserversionen in übergreifenden Kontexten blockiert werden. Dieses Verhalten schützt Benutzerdaten vor cross-site tracking. Siehe Cookies mit unabhängigem partitioniertem Zustand (CHIPS) und Drittanbieter-Cookies.

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, etc.) verhindert. Cookies mit diesem Attribut können weiterhin entweder mit Zugriff auf die Festplatte des Clients oder durch JavaScript gelesen/verändert werden, 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.

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

Set-Cookie: sessionId=38afes7a8

Permanente Cookies werden an einem spezifischen Datum entfernt (Expires) oder nach einer bestimmten Zeitspanne (Max-Age) 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 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

Cookienamen mit dem Präfix __Secure- oder __Host- können nur verwendet werden, wenn sie mit dem secure-Attribut von einer sicheren (HTTPS) Herkunft gesetzt werden.

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