Cookie-Attribute

Wenn ein Webserver auf eine Anfrage für eine Ressource antwortet, kann er seiner Antwort einen Set-Cookie-Header hinzufügen. Dieser Header weist Ihren Browser an, ein Cookie zu speichern. Beispiel: Set-Cookie:cat=tabby Unter Was sind Cookies? wird die Funktionsweise von Cookies erläutert.

Neben einem Cookienamen und ‑wert kann Set-Cookie auch Attribute enthalten, mit denen gesteuert wird, ob Cookies gesetzt werden und wann sie ablaufen. Cookie-Attribute werden durch Semikolons getrennt. Beispiel:

    Set-Cookie:cat=tabby; Secure; HTTPOnly; Expires=Tue, 31 Dec 2999 23:59:59 GMT;

In diesem Dokument werden die wichtigsten Cookie-Attribute erläutert:

Unter HTTP-Cookies verwenden werden Cookie-Attribute genauer beschrieben.

Sicher

Wenn ein Set-Cookie-Header Secure enthält, wird das Cookie nur in verschlüsselten Anfragen mit dem HTTPS-Protokoll eingefügt. Es wird nicht in HTTP-Anfragen eingefügt. So können Man-in-the-Middle-Angriffe verhindert werden, bei denen ein Angreifer heimlich in die Kommunikation zwischen dem Browser und dem Server eingreift, um Informationen weiterzugeben und möglicherweise zu ändern.

👉 Sie sollten Secure standardmäßig für alle Cookies einfügen.

HTTPOnly

Wenn ein Set-Cookie-Header HTTPOnly enthält, kann mit document.cookie nicht auf das Cookie zugegriffen werden. So können Sie sich vor bestimmten Arten von Angriffen schützen, die auf Cookies abzielen.

👉 Sie sollten HTTPOnly standardmäßig für alle Cookies einfügen. Lassen Sie das Feld nur weg, wenn Sie Cookie-Werte mit JavaScript festlegen und abrufen müssen.

SameSite

Eine Anfrage für eine Ressource von einer Website, die sich von der besuchten Website unterscheidet, ist eine websiteübergreifende Anfrage. Ein Cookie, das als Reaktion auf eine websiteübergreifende Anfrage gesetzt wird, wird als Drittanbieter-Cookie bezeichnet.

Mit dem Attribut SameSite wird gesteuert, ob ein Drittanbieter-Cookie in eine Anfrage einbezogen wird. Es hat drei mögliche Werte: Strict, Lax oder None.

👉 SameSite=Lax ist der Standardwert, wenn kein Wert festgelegt ist. SameSite=None lässt Website-übergreifende Cookies zu, aber Cookies werden blockiert, wenn Einschränkungen für Drittanbieter-Cookies gelten.

Weitere Informationen zu Drittanbieter-Cookies

Strikt

Das Cookie wird nur als Antwort auf Anfragen von einer Seite gesendet, die sich auf der Ursprungswebsite des Cookies befindet. Angenommen, ein Nutzer besucht cats.example und es wird ein Cookie mit dem Attribut SameSite=Strict gesetzt. Später befindet sich der Nutzer auf einer anderen Website und folgt einem Link zu einer Seite auf cats.example. Das gesetzte Cookie wird nicht in diese Anfrage aufgenommen.

Lax

Das funktioniert genauso wie Strict, mit dem Unterschied, dass der Browser das Cookie auch dann einfügt, wenn der Nutzer einem Link zur Ursprungswebsite des Cookies folgt. Im vorherigen Beispiel Strict wird das Cookie eingeschlossen, wenn der Nutzer dem Link zu cats.example folgt. Lax ist die Standardeinstellung, wenn in einem Set-Cookie-Header kein SameSite-Attribut enthalten ist.

Keine

Keine Einschränkungen: Das Cookie wird in eine Anfrage aufgenommen, unabhängig davon, ob es sich um eine websiteübergreifende Anfrage handelt. Bei SameSite=None muss das Cookie auch das Attribut Secure haben.

Partitioniert

Mit diesem Attribut können Sie ein Cookie für den partitionierten Speicher aktivieren. Dabei wird für jede Website der obersten Ebene ein separater „Cookie-Speicher“ verwendet. Das Cookie ist doppelt verschlüsselt, sowohl durch die Top-Level-Website als auch durch die Domain, die es festlegt.

Beispiel: Website A und Website B enthalten beide einen iFrame von Website C. Auf ein partitioniertes Cookie, das vom iFrame auf Website A gesetzt wird, kann nicht vom iFrame auf Website B zugegriffen werden: Das AC-Cookie ist vom BC-Cookie getrennt.

👉 Sie sollten das Attribut Partitioned standardmäßig einfügen, wenn Sie ein Drittanbieter-Cookie erstellen, es sei denn, Sie wissen ausdrücklich, dass es für mehrere Einbettungen freigegeben werden muss.

Diagramm, das zeigt, dass zwei verschiedene Websites, die einen gemeinsamen Drittanbieter einbetten, keine Cookies für diesen Drittanbieter mehr gemeinsam nutzen.
Bei der Cookie-Partitionierung kann ein Drittanbieterdienst, der ein Cookie setzt, wenn er in eine Top-Level-Website eingebettet ist, nicht auf dasselbe Cookie zugreifen, wenn der Dienst in andere Top-Level-Websites eingebettet ist.

Cookies mit dem Attribut Partitioned werden als CHIPS bezeichnet: Cookies Having Independent Partitioned State.

Partitionierte Cookies müssen das Attribut Secure haben.

Weitere Informationen

Ablaufdatum und „Max-Age“

Sie können ein Expires-Datum und eine Expires-Uhrzeit oder eine Max-Age in Sekunden angeben, nach der ein Cookie gelöscht und nicht mehr gesendet werden soll. Beispiel:

  • Set-Cookie:cat=tabby; Expires=Tue, 31 Dec 2999 23:59:59 GMT;
  • Set-Cookie:cat=tabby; Max-Age=86400

Wenn Sie kein Max-Age- oder Expires-Attribut angeben, wird ein Cookie gelöscht, wenn die aktuelle Sitzung endet. Diese Art von Cookie wird manchmal auch als Sitzungscookie bezeichnet.

👉 Lassen Sie die Attribute Max-Age und Expires weg, es sei denn, ein Cookie soll länger als die aktuelle Sitzung gültig sein. Browser löschen Cookies nach Ablauf der Gültigkeitsdauer. Es ist also nicht sinnvoll, ein Ablaufdatum festzulegen, das in ferner Zukunft liegt. Stattdessen sollten Sie Cookies aktualisieren, wenn ein Nutzer Ihre Website noch einmal besucht.

Domain

Wenn ein Set-Cookie-Header ein Domain-Attribut hat, wird das Cookie in Anfragen an die angegebene Domain und alle zugehörigen Subdomains eingefügt.

Wenn ein Set-Cookie-Header kein Domain-Attribut hat, wird das Cookie nicht in Anfragen an Subdomains aufgenommen.

Mit dem Attribut Domain werden die Domaineinschränkungen also verringert.

Beispiel:cats.example

  • Set-Cookie:cat=tabby
    Das Cookie wird nur in Anfragen an cats.example eingefügt.
  • Set-Cookie:cat=tabby; Domain=cats.example
    Das Cookie wird in Anfragen an cats.example sowie in Anfragen für Ressourcen in Subdomains wie fluffy.cats.example oder user.assets.cats.example enthalten.

👉 Sofern Sie nicht möchten, dass ein Cookie in Anfragen an Subdomains enthalten ist, sollten Sie kein Domain-Attribut angeben.

Pfad

Wenn ein Path-Attribut in einem Set-Cookie-Antwortheader enthalten ist, wird das festgelegte Cookie nur in Anfragen an URLs (auf der Website, auf der das Cookie festgelegt wurde) berücksichtigt, die mit dem Path-Wert übereinstimmen.

Beispiel:

  • Set-Cookie:cat=tabby; Path=/articles
    Das Cookie wird in Anfragen an alle URL-Pfade eingefügt, die mit /articles beginnen:
    ✅ https://cats.example/articles/tabby/index.html
    ✅ https://cats.example/articles/breeds/tabby/index.html
    ❎ https://cats.example/images/tabby.jpg
    ❎ https://cats.example/en/articles/tabby/index.html
  • Set-Cookie:cat=tabby; Path=/
    Alle Anfragen an eine beliebige URL auf der Website enthalten das Cookie.

Wenn ein Set-Cookie-Antwortheader keinen Path-Wert hat, wird das Cookie nur in Anfragen an dasselbe Verzeichnis eingefügt. Angenommen, ein cat=tabby-Cookie wird als Reaktion auf eine Anfrage für cats.example/images/tabby.jpg. festgelegt. Wenn kein Path festgelegt ist, wird das Cookie nur in Anfragen für Dateien im Verzeichnis cats.example/images berücksichtigt.

👉 Fügen Sie Path=/ mit einem Cookie ein, wenn alle Anfragen an einen beliebigen Pfad auf Ihrer Website das Cookie enthalten sollen. Verlassen Sie sich nicht auf Path, um Ihre Sicherheit zu schützen.

Demos

Tools

Weitere Informationen