Set-Cookie header
Baseline
Widely available
*
This feature is well established and works across many devices and browser versions. It’s been available across browsers since Juli 2015.
* Some parts of this feature may have varying levels of support.
Der HTTP Set-Cookie
Antwort-Header wird verwendet, um ein Cookie vom Server an den Benutzeragenten zu senden, damit der Benutzeragent es später an den Server zurücksenden kann.
Um mehrere Cookies zu senden, sollten in derselben Antwort mehrere Set-Cookie
-Header gesendet werden.
Warnung:
Browser blockieren JavaScript-Frontendcode daran, auf den Set-Cookie
-Header zuzugreifen, wie es von der Fetch-Spezifikation verlangt wird, die Set-Cookie
als einen verbotenen Antwort-Header-Namen definiert, der aus jedem dem Frontendcode zugänglichen Antwort-Header herausgefiltert werden muss.
Wenn eine Fetch API oder XMLHttpRequest API Anfrage CORS verwendet, ignorieren Browser die im Antwort-Header des Servers enthaltenen Set-Cookie
-Header, es sei denn, die Anfrage enthält Anmeldeinformationen. Besuchen Sie die Seiten Using the Fetch API - Including credentials und den Artikel zu XMLHttpRequest, um zu erfahren, wie Anmeldeinformationen einbezogen werden.
Weitere Informationen finden Sie im Leitfaden zur Verwendung von HTTP-Cookies.
Header-Typ | Antwort-Header |
---|---|
Verbotener Anfrage-Header | 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 Namen des Cookies und dessen Wert. Eine Cookie-Definition beginnt mit einem Name-Wert-Paar.
Ein
<cookie-name>
kann alle US-ASCII-Zeichen außer Steuerzeichen (ASCII Zeichen 0 bis 31 und ASCII-Zeichen 127) oder Trennzeichen (Leerzeichen, Tab und die Zeichen:( ) < > @ , ; : \ " / [ ] ? = { }
) enthalten.Ein
<cookie-value>
kann optional in Anführungszeichen gesetzt werden und jedes US-ASCII-Zeichen außer Steuerzeichen (ASCII-Zeichen 0 bis 31 und ASCII-Zeichen 127), Leerzeichen, Anführungszeichen, Kommas, Semikolons und Rückwärtsschrägen enthalten.Kodierung: Viele Implementierungen führen eine Prozent-Codierung der Cookie-Werte durch. Dies ist jedoch nicht durch die RFC-Spezifikation vorgeschrieben. Die Prozent-Codierung hilft, die Anforderungen der für
<cookie-value>
erlaubten Zeichen zu erfüllen.Hinweis: Einige Cookie-Namen enthalten Präfixe, die bestimmte Einschränkungen für die Attribute des Cookies bei unterstützenden Benutzeragenten auferlegen. Weitere Informationen finden Sie unter Cookie-Präfixe.
Domain=<domain-value>
Optional-
Definiert den Host, an den das Cookie gesendet wird.
Nur die aktuelle Domain oder eine Domain höherer Ordnung kann als Wert gesetzt werden, sofern diese kein öffentlicher Suffix ist. Die Festlegung der Domain macht das Cookie sowohl für diese als auch für alle ihre Subdomains verfügbar.
Wenn dieses Attribut weggelassen wird, wird es standardmäßig auf den Host der aktuellen Dokument-URL gesetzt, ohne Subdomains einzuschließen.
Im Gegensatz zu früheren Spezifikationen werden führende Punkte in Domainnamen (
.example.com
) ignoriert.Mehrere Host-/Domainwerte sind nicht zulässig, aber wenn eine Domain angegeben wird, sind Subdomains immer enthalten.
Expires=<date>
Optional-
Gibt die maximale Lebensdauer des Cookies als HTTP-Datum-Zeitstempel 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, nach welchem das Sitzungscookie entfernt wird.
Warnung: Viele Webbrowser verfügen über eine Sitzungswiederherstellung, die alle Registerkarten speichert und sie beim nächsten Browserstart wiederherstellt. Sitzungscookies werden ebenfalls wiederhergestellt, als ob der Browser nie geschlossen worden wäre.
Das
Expires
-Attribut wird vom Server mit einem Wert im Verhältnis zu seiner eigenen internen Uhr gesetzt, die von der der Client-Browsers abweichen kann. Firefox und Chromium-basierte Browser verwenden intern einen Ablaufwert (max-age), der angepasst wird, um Uhrzeitunterschiede zu kompensieren, indem Cookies gemäß der vom Server beabsichtigten Zeit gespeichert und abgelaufen werden. Die Anpassung für Zeitschwankungen wird aus dem Wert desDATE
-Headers berechnet. Beachten Sie, dass die Spezifikation erklärt, wie das Attribut analysiert werden sollte, aber nicht, ob/wie der Wert vom Empfänger korrigiert werden sollte. HttpOnly
Optional-
Verbietet JavaScript den Zugriff auf das Cookie, zum Beispiel über die
Document.cookie
-Eigenschaft. Beachten Sie, dass ein Cookie, das mitHttpOnly
erstellt wurde, dennoch mit von JavaScript initiierten Anfragen gesendet wird, zum Beispiel bei Aufrufen vonXMLHttpRequest.send()
oderfetch()
. Dies verringert Angriffe gegen Cross-Site-Scripting (XSS). Max-Age=<number>
Optional-
Gibt die Anzahl der Sekunden bis zum Ablauf des Cookies an. Eine Null oder 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 in einer partitionierten Speicherung gespeichert werden soll. Beachten Sie, dass, wenn dies gesetzt ist, auch die
Secure
-Direktive gesetzt sein 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, damit der Browser den
Cookie
-Header bei der angeforderten URL sendet.Wenn dieses Attribut weggelassen wird, wird es standardmäßig auf den Pfadanteil der Anforderungs-URL gesetzt. Zum Beispiel, wenn ein Cookie durch eine Anfrage an
https://example.com/docs/Web/HTTP/index.html
gesetzt wird, wäre der Standardpfad/docs/Web/HTTP/
.Der Schrägstrich (
/
) wird als Verzeichnistrennzeichen interpretiert, und Unterverzeichnisse werden ebenfalls abgeglichen. Zum Beispiel, fürPath=/docs
,- werden die Anforderungspfade
/docs
,/docs/
,/docs/Web/
, und/docs/Web/HTTP
alle übereinstimmen. - die Anforderungspfade
/
,/docsets
,/fr/docs
werden nicht übereinstimmen.
Hinweis: Das
path
-Attribut ermöglicht es Ihnen, zu steuern, welche Cookies der Browser basierend auf den unterschiedlichen Teilen einer Seite sendet. Es ist nicht als Sicherheitsmaßnahme gedacht und schützt nicht vor unautorisiertem Auslesen des Cookies von einem anderen Pfad. - werden die Anforderungspfade
SameSite=<samesite-value>
Optional-
Kontrolliert, ob ein Cookie mit Cross-Site-Anfragen gesendet wird: das heißt Anfragen, die von einer anderen Seite, einschließlich des Schemas, als die Seite, die das Cookie gesetzt hat, ausgehen. 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 ausgehen, die das Cookie gesetzt hat.
Lax
-
Sendet das Cookie nur für Anfragen, die von derselben Seite ausgehen, 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: das bedeutet im Wesentlichen, dass die Anfrage die im Adressfeld des Browsers angezeigte URL ändert.
-
Dies würde zum Beispiel Anfragen ausschließen, die die
fetch()
API verwenden, oder Anfragen für Subressourcen von<img>
- oder<script>
-Elementen, oder Navigationen innerhalb von<iframe>
-Elementen. -
Es würden jedoch Anfragen enthalten sein, die erfolgen, wenn der Benutzer einen Link im Top-Level-Browsing-Kontext von einer Seite zu einer anderen anklickt, oder eine Zuweisung zu
document.location
, oder das Absenden eines<form>
-Formulars.
-
-
Die Anfrage verwendet eine sichere Methode: insbesondere sind damit
POST
,PUT
, undDELETE
ausgeschlossen.
Einige Browser verwenden
Lax
als Standardwert, wennSameSite
nicht angegeben ist: siehe Browser-Kompatibilität für Details.Hinweis: Wenn
Lax
als Standard angewendet wird, wird eine permissivere Version verwendet. In dieser permissiveren Version sind Cookies auch inPOST
-Anfragen enthalten, 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 ebenfalls gesetzt sein, wenn dieser Wert verwendet wird.
Secure
Optional-
Gibt an, dass das Cookie nur dann an den Server gesendet wird, wenn eine Anfrage mit dem Schema
https:
(außer auf localhost) erfolgt und somit widerstandsfähiger gegen Man-in-the-Middle 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 weiterhin entweder mit Zugriff auf die Festplatte des Clients oder von JavaScript aus gelesen/geändert werden, wenn dasHttpOnly
-Cookie-Attribut nicht gesetzt ist.Unsichere Seiten (
http:
) können keine Cookies mit demSecure
-Attribut setzen. Diehttps:
-Anforderungen werden ignoriert, wenn dasSecure
-Attribut von localhost gesetzt ist.
Cookie-Präfixe
Einige Cookie-Namen enthalten Präfixe, die bestimmte Einschränkungen für die 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 AttributSecure
von einer sicheren Seite (HTTPS) gesetzt werden.__Host-
: Cookies mit Namen, die mit__Host-
beginnen, müssen mit dem AttributSecure
von einer sicheren Seite (HTTPS) gesetzt werden. Zusätzlich dürfen sie keinDomain
-Attribut haben, und dasPath
-Attribut muss auf/
gesetzt sein. Dies gewährleistet, dass solche Cookies nur an den Host, der sie gesetzt hat, gesendet werden, und nicht an einen anderen Host in der Domain. Es garantiert auch, dass sie Host-weit gesetzt sind und auf keinem Pfad auf diesem Host überschrieben werden können. Diese Kombination ergibt ein Cookie, das so nah wie möglich an einer Sicherheitsgrenze behandelt wird.__Http-
: Cookies mit Namen, die mit__Http-
beginnen, müssen mit demSecure
-Attribut von einer sicheren Seite (HTTPS) gesetzt werden und zusätzlich muss dasHttpOnly
-Attribut gesetzt sein, um zu beweisen, dass sie über denSet-Cookie
-Header gesetzt wurden (sie können nicht oder verändert über JavaScript-Funktionen wieDocument.cookie
oder die Cookie-Store-API gesetzt werden).__Host-Http-
: Cookies mit Namen, die mit__Host-Http-
beginnen, müssen mit demSecure
-Attribut von einer sicheren Seite (HTTPS) gesetzt werden und müssen dasHttpOnly
-Attribut haben, um zu beweisen, dass sie über denSet-Cookie
-Header gesetzt wurden. Zusätzlich haben sie dieselben Einschränkungen wie__Host-
-präfixierte Cookies. Diese Kombination ergibt ein Cookie, das so nah wie möglich an einer Sicherheitsgrenze behandelt wird, während gleichzeitig sichergestellt wird, dass Entwickler und Serverbetreiber wissen, dass sein Umfang auf HTTP-Anfragen beschränkt ist.
Warnung: Sie können sich nicht auf diese zusätzlichen Zusicherungen bei Browsern verlassen, die keine Cookie-Präfixe unterstützen; in solchen Fällen werden Cookies mit Präfix stets akzeptiert.
Beispiele
>Sitzungscookie
Sitzungscookies werden entfernt, wenn der Client heruntergefahren wird. Cookies sind Sitzungscookies, wenn sie nicht das Expires
oder Max-Age
-Attribut spezifizieren.
Set-Cookie: sessionId=38afes7a8
Permanentes 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 den Server, der es gesetzt hat, nicht einschließt, sollte vom Benutzeragenten abgelehnt werden.
Das folgende Cookie wird abgelehnt, wenn es von einem auf original-company.com
gehosteten Server gesetzt wird:
Set-Cookie: qwerty=219ffwef9w0f; Domain=some-company.co.uk
Ein Cookie für eine Subdomain der bereitstellenden Domain wird abgelehnt.
Das folgende Cookie wird abgelehnt, wenn es von einem auf example.com
gehosteten Server gesetzt wird:
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
Cookie-Präfixe
Cookie-Namen, die mit __Secure-
oder __Host-
anfangen, können nur verwendet werden, wenn sie mit dem Secure
-Attribut von einem sicheren (HTTPS) Ursprung gesetzt werden.
Cookie-Namen, die mit __Http-
oder __Host-Http-
anfangen, können nur verwendet werden, wenn sie mit dem Secure
-Attribut von einem sicheren (HTTPS) Ursprung gesetzt werden und zusätzlich muss das HttpOnly
-Attribut gesetzt sein, um zu beweisen, dass sie über den Set-Cookie
-Header gesetzt wurden und nicht clientseitig über JavaScript.
Zusätzlich müssen Cookies mit dem __Host-
oder __Host-Http-
Präfix den Pfad /
haben (was bedeutet, auf jedem Pfad des Hosts) 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=/
Partitioniertes Cookie
Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
Hinweis:
Partitionierte Cookies müssen mit Secure
festgelegt werden. Es wird zudem empfohlen, beim Setzen partitionierter Cookies ein __Host
oder __Host-Http-
Präfix zu verwenden, 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
Loading…
Siehe auch
- HTTP-Cookies
Cookie
Document.cookie
- Samesite-Cookies erklärt (web.dev-Blog)