Set-Cookie
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
Der HTTP-Antwortheader Set-Cookie
wird verwendet, um ein Cookie vom Server an den Benutzeragenten zu senden, sodass der Benutzeragent es später an den Server zurücksenden kann. Um mehrere Cookies zu senden, sollten mehrere Set-Cookie
-Header in derselben Antwort gesendet werden.
Warnung: Browser blockieren JavaScript-Code im Frontend vom Zugriff auf den Set-Cookie
-Header, wie es die Fetch-Spezifikation verlangt, die Set-Cookie
als einen verbotenen Antwort-Header-Namen definiert, der aus jeder Antwort herausgefiltert werden muss, die Frontend-Code zugänglich ist.
Wenn eine Fetch API oder eine XMLHttpRequest-API Anfrage CORS verwendet, ignorieren Browser Set-Cookie
-Header im Server-Antwort, es sei denn, die Anfrage enthält Anmeldeinformationen. Besuchen Sie Verwendung der Fetch API - Inklusive Anmeldeinformationen und den XMLHttpRequest-Artikel, um zu erfahren, wie Anmeldeinformationen einbezogen werden.
Weitere Informationen finden Sie im Leitfaden über Die Verwendung von HTTP-Cookies.
Headertyp | Antwortheader |
---|---|
Verbotener Header-Name | nein |
Verbotener Antwort-Header-Name | ja |
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
-
Definiert den Cookie-Namen und dessen Wert. 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 werden und alle US-ASCII-Zeichen enthalten, außer Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127), Whitespace, Anführungszeichen, Kommas, Semikolons und Backslashes.Codierung: Viele Implementierungen verwenden Prozent-Codierung für Cookie-Werte. Dies ist jedoch nicht von der RFC-Spezifikation vorgeschrieben. Die Prozent-Codierung hilft jedoch, 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-
(der Bindestrich ist Teil des Präfixes) beginnen, müssen mit demsecure
-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 einen anderen Host. Sie müssen mit demsecure
-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 gesetzt werden oder eine Domain höherer Ordnung, sofern es sich nicht um ein öffentliches Suffix handelt. Wenn die Domain gesetzt wird, wird das Cookie sowohl für diese als auch für alle ihre Subdomains verfügbar gemacht.
Wird dieses Attribut weggelassen, wird standardmäßig der Host der aktuellen Dokument-URL ohne Subdomains verwendet.
Entgegen 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 die Subdomains immer einbezogen.
Expires=<date>
Optional-
Gibt die maximale Lebensdauer des Cookies als HTTP-Datum-Stempel an. Siehe
Date
für das erforderliche Format.Wenn nicht angegeben, wird das Cookie zu einem Sitzungs-Cookie. Eine Sitzung endet, wenn der Client heruntergefahren wird, wonach das Sitzungscookie entfernt wird.
Warnung: Viele Webbrowser haben eine Sitzungswiederherstellungsfunktion, die alle Tabs speichert und sie beim nächsten Gebrauch des Browsers wiederherstellt. Sitzungscookies werden ebenfalls wiederhergestellt, als wäre der Browser nie geschlossen worden.
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, beispielsweise über die
Document.cookie
Eigenschaft. Beachten Sie, dass ein Cookie, das mitHttpOnly
erstellt wurde, trotzdem mit JavaScript-initiierten Anfragen gesendet wird, zum Beispiel beim Aufruf vonXMLHttpRequest.send()
oderfetch()
. Dies mildert Angriffe gegen Cross-Site-Scripting (XSS) ab. Max-Age=<number>
Optional-
Gibt die Anzahl der Sekunden an, bis das Cookie abläuft. Eine Null oder eine negative Zahl wird das Cookie sofort ablaufen lassen. Wenn sowohl
Expires
als auchMax-Age
gesetzt sind, hatMax-Age
Vorrang. Partitioned
Optional-
Gibt an, dass das Cookie mithilfe eines partitionierten Speichers gespeichert werden soll. Beachten Sie, dass in diesem Fall die
Secure
-Richtlinie ebenfalls gesetzt werden muss. Siehe Cookies mit unabhängigem partitioniertem Status (CHIPS) für weitere Details. Path=<path-value>
Optional-
Gibt den Pfad an, der vorhanden sein muss in der angeforderten URL, damit der Browser den
Cookie
-Header sendet.Das Schrägstrich-Zeichen (
/
) wird als Verzeichnistrennzeichen interpretiert, und Unterverzeichnisse werden ebenfalls abgeglichen. Zum Beispiel, fürPath=/docs
,- stimmen die Pfadanfragen
/docs
,/docs/
,/docs/Web/
und/docs/Web/HTTP
überein. - die Pfadanfragen
/
,/docsets
,/fr/docs
stimmen nicht überein.
- stimmen die Pfadanfragen
SameSite=<samesite-value>
Optional-
Steuert, ob ein Cookie mit bereichsübergreifenden Anfragen gesendet wird und bietet einen gewissen Schutz gegen Cross-Site-Request-Forgery-Angriffe (CSRF).
Die möglichen Attributwerte sind:
Strict
-
Bedeutet, dass der Browser das Cookie nur bei bereichsinternen 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 stammt (selbst mit derselben Domain), werden keine Cookies mit dem Attribut
SameSite=Strict
gesendet. Lax
-
Bedeutet, dass das Cookie nicht bei bereichsübergreifenden Anfragen gesendet wird, wie zum Beispiel bei Anfragen zum Laden von Bildern oder Frames, jedoch gesendet wird, wenn ein Benutzer von einer externen Seite auf die Ursprungsseite navigiert (zum Beispiel beim Folgen eines Links). Dies ist das Standardverhalten, wenn das
SameSite
-Attribut nicht angegeben ist. None
-
Bedeutet, dass der Browser das Cookie sowohl bei bereichsübergreifenden als auch bei bereichsinternen Anfragen sendet. Das
Secure
-Attribut muss ebenfalls gesetzt sein, wenn dieser Wert gesetzt wird, also soSameSite=None; Secure
. WennSecure
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. Beachten Sie, dass nicht sichere Seiten (http:
) keine Cookies mit derSecure
-Richtlinie setzen können und daherSameSite=None
nicht verwenden können.Warnung: Cookies mit
SameSite=None; Secure
, die nicht auch dasPartitioned
-Attribut haben, könnten in bereichsübergreifenden Kontexten in zukünftigen Browserversionen blockiert werden. Dieses Verhalten schützt Benutzerdaten vor bereichsübergreifendem Tracking. Siehe Cookies mit unabhängigem partitioniertem Status (CHIPS) und Third-party 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
allen Zugriff auf sensible Informationen in Cookies verhindert (Sitzungsschlüssel, Anmeldedaten usw.). Cookies mit diesem Attribut können weiterhin entweder mit Zugriff auf die Festplatte des Clients gelesen/geändert werden oder aus JavaScript, wenn dasHttpOnly
Cookie-Attribut nicht gesetzt ist.Unsichere Seiten (
http:
) können keine Cookies mit demSecure
-Attribut setzen (seit Chrome 52 und Firefox 52). Diehttps:
-Anforderungen werden ignoriert, wenn dasSecure
-Attribut von localhost gesetzt ist (seit Chrome 89 und Firefox 75).
Beispiele
Sitzungscookie
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
Permanent-Cookie
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
Ungültige Domains
Ein Cookie für eine Domain, die nicht den Server enthält, 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 aufrufenden 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, die 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 /
(was jeden Pfad am Host bedeutet) haben und dürfen kein Domain
-Attribut haben.
Warnung: Für Clients, die keine Cookie-Präfixe implementieren, können Sie auf diese zusätzlichen Absicherungen nicht zählen, und präfixte Cookies werden immer akzeptiert.
// 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
Partitioniertes Cookie
Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
Hinweis: Partitionierte Cookies müssen mit Secure
gesetzt werden. Darüber hinaus wird empfohlen, das __Host
-Präfix zu verwenden, wenn partitionierte Cookies gesetzt werden, um sie an den Hostnamen und nicht an die registrierbare Domain zu binden.
Spezifikationen
Specification |
---|
HTTP State Management Mechanism # sane-set-cookie |
Browser-Kompatibilität
BCD tables only load in the browser
Kompatibilitäts-Hinweise
- Ab Chrome 52 und Firefox 52 können unsichere Seiten (
http:
) keine Cookies mehr mit demSecure
-Attribut setzen.
Siehe auch
- HTTP-Cookies
Cookie
Document.cookie
- Samesite-Cookies erklärt (web.dev Blog)