Verwendung von HTTP-Cookies

In der Regel verwendet der Server die Inhalte von HTTP-Cookies, um zu bestimmen, ob verschiedene Anfragen vom selben Browser/Nutzer stammen, und gibt dann eine personalisierte oder allgemeine Antwort aus, je nach Bedarf. Im Folgenden wird ein einfaches Anmeldesystem für Benutzer beschrieben:

1. Der Benutzer sendet Anmeldedaten an den Server, zum Beispiel über ein Formular.
2. Wenn die Anmeldedaten korrekt sind, aktualisiert der Server die Benutzeroberfläche, um anzuzeigen, dass der Benutzer angemeldet ist, und antwortet mit einem Cookie, das eine Sitzungs-ID enthält, die den Anmeldestatus im Browser speichert.
3. Später wechselt der Benutzer zu einer anderen Seite auf derselben Website. Der Browser sendet das Cookie mit der Sitzungs-ID zusammen mit der entsprechenden Anfrage, um anzuzeigen, dass der Benutzer noch immer angemeldet ist.
4. Der Server überprüft die Sitzungs-ID und, wenn sie noch gültig ist, wird dem Benutzer eine personalisierte Version der neuen Seite gesendet. Wenn sie nicht gültig ist, wird die Sitzungs-ID gelöscht und dem Benutzer wird eine generische Version der Seite gezeigt (oder vielleicht eine "Zugriff verweigert"-Meldung mit der Aufforderung, sich erneut anzumelden).

Cookies werden hauptsächlich für drei Zwecke verwendet:

• Sitzungsverwaltung: Anmeldestatus des Benutzers, Einkaufswageninhalte, Spielstände oder andere sitzungsbezogene Details, die sich der Server merken muss.
• Personalisierung: Benutzereinstellungen wie Anzeigesprache und UI-Design.
• Verfolgung: Aufzeichnen und Analysieren des Benutzerverhaltens.

In den frühen Tagen des Web, als es keine andere Möglichkeit gab, wurden Cookies für allgemeine clientseitige Datenspeichereinsätze genutzt. Moderne Speicher-APIs werden jetzt empfohlen, zum Beispiel die Web Storage API (localStorage und sessionStorage) und IndexedDB.

Sie sind mit Blick auf die Speicherung konzipiert, senden nie Daten an den Server und bringen nicht die Nachteile mit sich, die das Speichern von Daten in Cookies mit sich bringt:

• Browser sind im Allgemeinen auf eine maximale Anzahl von Cookies pro Domain beschränkt (variiert je nach Browser, im Allgemeinen im dreistelligen Bereich) und eine maximale Größe pro Cookie (in der Regel 4KB). Speicher-APIs können größere Datenmengen speichern.
• Cookies werden mit jeder Anfrage gesendet, was die Performance verschlechtern kann (zum Beispiel bei langsamen mobilen Datenverbindungen), besonders wenn viele Cookies gesetzt sind.

Nachdem eine HTTP-Anfrage empfangen wurde, kann ein Server eine oder mehrere Set-Cookie-Header mit der Antwort senden, von denen jeder ein separates Cookie setzt. Ein Cookie wird gesetzt, indem ein Name-Wert-Paar angegeben wird, wie folgt:

Set-Cookie: <cookie-name>=<cookie-value>

Die folgende HTTP-Antwort weist den empfangenden Browser an, ein Paar von Cookies zu speichern:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=chocolate
Set-Cookie: tasty_cookie=strawberry

[page content]

Wenn eine neue Anfrage gestellt wird, sendet der Browser normalerweise zuvor gespeicherte Cookies für die aktuelle Domain zurück an den Server innerhalb eines Cookie HTTP-Headers:

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=chocolate; tasty_cookie=strawberry

Sie können ein Ablaufdatum oder eine Zeitdauer angeben, nach der das Cookie gelöscht werden soll und nicht mehr gesendet wird. Abhängig von den Attributen, die im Set-Cookie-Header gesetzt sind, wenn die Cookies erstellt werden, handelt es sich entweder um permanente oder Sitzungs-Cookies:

• Permanente Cookies werden nach dem im Expires-Attribut angegebenen Datum gelöscht:

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;
  

  oder nach der im Max-Age-Attribut angegebenen Zeitdauer:

  http

  Set-Cookie: id=a3fWa; Max-Age=2592000
  

  Hinweis:>Expires ist schon länger verfügbar als Max-Age, jedoch ist Max-Age weniger fehleranfällig und hat Vorrang, wenn beides gesetzt ist. Der Grund dafür ist, dass beim Setzen eines Expires-Datums und -Zeitpunkts, diese relativ zum Client sind, auf dem das Cookie gesetzt wird. Wenn der Server anders eingestellt ist, könnte dies zu Fehlern führen.

• Sitzungs-Cookies — Cookies ohne ein Max-Age- oder Expires-Attribut – werden gelöscht, wenn die aktuelle Sitzung endet. Der Browser definiert, wann die "aktuelle Sitzung" endet, und einige Browser verwenden Sitzungswiederherstellung beim Neustart. Dies kann dazu führen, dass Sitzungscookies unbegrenzt dauern.

  Hinweis: Wenn Ihre Website Benutzer authentifiziert, sollte sie Sitzungs-Cookies neu generieren und zurücksenden, auch solche, die bereits existieren, wann immer sich ein Benutzer authentifiziert. Dieser Ansatz hilft, Session Fixation-Angriffe zu verhindern, bei denen ein Dritter die Sitzung eines Benutzers wiederverwenden kann.

Es gibt einige Techniken, die darauf abzielen, Cookies nach ihrer Löschung wiederherzustellen. Diese sind als "Zombie-Cookies" bekannt. Solche Techniken verletzen die Grundsätze des Benutzer-Datenschutzes und der Kontrolle, können gegen Datenschutzbestimmungen verstoßen und eine Website, die sie verwendet, rechtlichen Risiken aussetzen.

Um ein Cookie per HTTP zu aktualisieren, kann der Server einen Set-Cookie-Header mit dem bestehenden Cookie-Namen und einem neuen Wert senden. Zum Beispiel:

Set-Cookie: id=new-value

Es gibt mehrere Gründe, warum Sie dies tun könnten, zum Beispiel, wenn ein Benutzer seine Präferenzen aktualisiert hat und die Anwendung die Änderungen in clientseitigen Daten widerspiegeln möchte (Sie könnten dies auch mit einem clientseitigen Speichermedium wie Web Storage tun).

Cookies über JavaScript aktualisieren

Im Browser können Sie neue Cookies über JavaScript mithilfe der Document.cookie-Eigenschaft oder der asynchronen Cookie Store API erstellen. Beachten Sie, dass alle unten stehenden Beispiele Document.cookie verwenden, da dies die am weitesten unterstützte/etablierte Option ist.

document.cookie = "yummy_cookie=chocolate";
document.cookie = "tasty_cookie=strawberry";

Sie können auch auf vorhandene Cookies zugreifen und neue Werte für sie setzen, vorausgesetzt, das HttpOnly-Attribut ist bei ihnen nicht gesetzt (d.h. im Set-Cookie-Header, der sie erstellt hat):

console.log(document.cookie);
// logs "yummy_cookie=chocolate; tasty_cookie=strawberry"

document.cookie = "yummy_cookie=blueberry";

console.log(document.cookie);
// logs "tasty_cookie=strawberry; yummy_cookie=blueberry"

Beachten Sie, dass Sie aus Sicherheitsgründen Cookie-Werte nicht durch das Senden eines aktualisierten Cookie-Headers direkt ändern können, wenn Sie eine Anfrage initiieren, d.h. über fetch() oder XMLHttpRequest. Beachten Sie, dass es auch gute Gründe gibt, warum Sie JavaScript nicht erlauben sollten, Cookies zu ändern — d.h. HttpOnly bei der Erstellung zu setzen. Weitere Details finden Sie im Abschnitt Sicherheit.

Wenn Sie Informationen in Cookies speichern, sind standardmäßig alle Cookie-Werte für den Endbenutzer sichtbar und können von ihm geändert werden. Sie sollten wirklich verhindern, dass Ihre Cookies missbraucht werden — zum Beispiel von böswilligen Akteuren zugegriffen/verändert oder an Domains gesendet werden, wo sie nicht gesendet werden sollten. Die potenziellen Konsequenzen können von ärgerlich bis katastrophal reichen. Ein Krimineller könnte zum Beispiel eine Sitzungs-ID stehlen und sie verwenden, um ein Cookie zu setzen, das ihn wie eine andere eingeloggte Person aussehen lässt, während er auf ihr Bank- oder E-Commerce-Konto zugreift.

Sie können Ihre Cookies auf verschiedene Weise sichern, die in diesem Abschnitt überprüft werden.

Sie können sicherstellen, dass Cookies sicher gesendet und nicht von unbeabsichtigten Parteien oder Skripten abgerufen werden, indem Sie entweder das Secure-Attribut oder das HttpOnly-Attribut verwenden:

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

• Ein Cookie mit dem Secure-Attribut wird nur mit einer verschlüsselten Anfrage über das HTTPS-Protokoll an den Server gesendet. Es wird nie mit ungesichertem HTTP gesendet (außer auf localhost), was bedeutet, dass man-in-the-middle-Angreifer nicht einfach darauf zugreifen können. Unsichere Seiten (mit http: in der URL) können keine Cookies mit dem Secure-Attribut setzen. Allerdings sollten Sie nicht annehmen, dass Secure sämtlichen Zugriff auf sensible Informationen in Cookies verhindert. Zum Beispiel kann jemand, der Zugriff auf die Festplatte des Clients hat (oder JavaScript, wenn das HttpOnly-Attribut nicht gesetzt ist), die Informationen lesen und ändern.

• Ein Cookie mit dem HttpOnly-Attribut kann von JavaScript, zum Beispiel mit Document.cookie, nicht abgerufen werden; es kann nur abgerufen werden, wenn es den Server erreicht. Cookies, die Benutzersitzungen beibehalten, sollten das HttpOnly-Attribut gesetzt haben — es wäre wirklich unsicher, sie für JavaScript zugänglich zu machen. Dieses Vorsichtsmaßnahme hilft, Cross-Site Scripting (XSS)-Angriffe zu entschärfen.

Die Attribute Domain und Path definieren den Geltungsbereich eines Cookies: an welche URLs die Cookies gesendet werden.

• Das Domain-Attribut gibt an, welcher Server ein Cookie empfangen kann. Wenn angegeben, sind Cookies auf dem angegebenen Server und dessen Subdomains verfügbar. Zum Beispiel, wenn Sie Domain=mozilla.org von mozilla.org setzen, sind Cookies auf dieser Domain und Subdomains wie developer.mozilla.org verfügbar.

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Domain=mozilla.org
  

  Wenn der Set-Cookie-Header kein Domain-Attribut angibt, sind die Cookies auf dem Server verfügbar, der sie setzt, nicht jedoch auf seinen Subdomains. Somit ist die Angabe des Domain-Attributs weniger restriktiv als das Weglassen. Beachten Sie, dass ein Server das Domain-Attribut nur auf seine eigene Domain oder eine übergeordnete Domain setzen kann, nicht auf eine Subdomain oder eine andere Domain. So könnte zum Beispiel ein Server mit der Domain foo.example.com das Attribut auf example.com oder foo.example.com setzen, jedoch nicht auf bar.foo.example.com oder elsewhere.com (die Cookies würden jedoch an Subdomains wie bar.foo.example.com gesendet). Weitere Informationen finden Sie unter Ungültige Domains.

• Das Path-Attribut gibt einen URL-Pfad an, der in der angeforderten URL existieren muss, um den Cookie-Header zu senden. Zum Beispiel:

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Path=/docs
  

  Das %x2F ("/")-Zeichen wird als Verzeichnistrenner betrachtet, und auch Unterverzeichnisse werden übereinstimmend behandelt. Zum Beispiel, wenn Sie Path=/docs setzen, entsprechen diese Anfragepfade:

  • /docs
  • /docs/
  • /docs/Web/
  • /docs/Web/HTTP

  Aber diese Anfragepfade nicht:

  • /
  • /docsets
  • /fr/docs

  Hinweis: Das path-Attribut ermöglicht Ihnen die Kontrolle darüber, welche Cookies der Browser je nach den verschiedenen Teilen einer Website sendet. Es ist nicht als Sicherheitsmaßnahme gedacht und schützt nicht vor unbefugtem Lesen des Cookies von einem anderen Pfad.

Das SameSite-Attribut erlaubt es Servern zu spezifizieren, ob/wann Cookies bei Anfragen von Drittanbietern gesendet werden — d.h. Drittanbieter-Cookies. Anfragen von Drittanbietern sind Anfragen, bei denen die Seite (die registrierbare Domain) und/oder das Schema (http oder https) nicht mit der Seite übereinstimmen, die der Benutzer aktuell besucht. Dazu gehören Anfragen, die beim Klicken auf Links auf anderen Seiten gesendet werden, um zu Ihrer Seite zu navigieren, sowie alle Anfragen, die von eingebetteten Inhalten von Drittanbietern gesendet werden.

SameSite hilft, das Auslaufen von Informationen zu verhindern, den Benutzer-Datenschutz zu wahren und bietet einen gewissen Schutz vor Cross-Site Request Forgery-Angriffen. Es nimmt drei mögliche Werte: Strict, Lax und None:

• Strict bewirkt, dass der Browser das Cookie nur auf Anfragen schickt, die von der Ursprungsseite des Cookies stammen. Dies sollte verwendet werden, wenn Sie Cookies haben, die sich auf Funktionen beziehen, die immer hinter einer initialen Navigation sein werden, wie Authentifizierung oder das Speichern von Einkaufswageninformationen.

  http

  Set-Cookie: cart=110045_77895_53420; SameSite=Strict
  

  Hinweis: Cookies, die für sensible Informationen verwendet werden, sollten auch eine kurze Lebensdauer haben.

• Lax ist ähnlich, außer dass der Browser das Cookie auch sendet, wenn der Benutzer zur Ursprungsseite des Cookies navigiert (auch wenn der Benutzer von einer anderen Seite kommt). Dies ist nützlich für Cookies, die die Darstellung einer Site betreffen – zum Beispiel könnten Sie Produktinformationen mit einem Partnerprodukt zusammen mit einem Affiliate-Link auf Ihrer Website haben. Wenn dieser Link auf die Partnerwebsite gefolgt wird, möchten sie möglicherweise ein Cookie setzen, das angibt, dass der Affiliate-Link gefolgt wurde, was ein Belohnungsbanner anzeigt und einen Rabatt bietet, wenn das Produkt gekauft wird.

  http

  Set-Cookie: affiliate=e4rt45dw; SameSite=Lax
  

• None gibt an, dass Cookies sowohl bei ursprungs- als auch fremdseitigen Anfragen gesendet werden. Dies ist nützlich, wenn Sie Cookies zusammen mit Anfragen senden möchten, die von eingebettetem Drittanbieter-Inhalt in anderen Seiten gemacht werden, zum Beispiel von Anbietern von Werbetechnologie oder Analysen. Beachten Sie, dass, wenn SameSite=None gesetzt ist, auch das Secure-Attribut gesetzt werden muss — SameSite=None erfordert einen sicheren Kontext.

  http

  Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly
  

Wenn kein SameSite-Attribut gesetzt ist, wird das Cookie standardmäßig als Lax behandelt.

Aufgrund des Designs des Cookie-Mechanismus kann ein Server nicht bestätigen, dass ein Cookie von einem sicheren Ursprung gesetzt wurde oder sogar feststellen, wo ein Cookie ursprünglich gesetzt wurde.

Eine Anwendung auf einer Subdomain kann ein Cookie mit dem Domain-Attribut setzen, was den Zugriff auf dieses Cookie auf alle anderen Subdomains ermöglicht. Dieser Mechanismus kann in einem Session Fixation-Angriff missbraucht werden.

Als Defense-in-Depth-Maßnahme, jedoch, können Sie Cookie-Präfixe verwenden, um bestimmte Fakten über das Cookie zu überprüfen. Zwei Präfixe sind verfügbar:

• __Host-: Wenn ein Cookie-Name dieses Präfix hat, wird es in einem Set-Cookie-Header nur akzeptiert, wenn es auch das Secure-Attribut hat, von einem sicheren Ursprung gesendet wird, kein Domain-Attribut enthält und das Path-Attribut auf / gesetzt ist. Mit anderen Worten, das Cookie ist domain-gesperrt.
• __Secure-: Wenn ein Cookie-Name dieses Präfix hat, wird es in einem Set-Cookie-Header nur akzeptiert, wenn es mit dem Secure-Attribut markiert ist und von einem sicheren Ursprung gesendet wird. Dies ist schwächer als das __Host--Präfix.

Der Browser wird Cookies mit diesen Präfixen ablehnen, die nicht mit ihren Einschränkungen übereinstimmen. Dies stellt sicher, dass von einer Subdomain erstellte Cookies mit Präfixen entweder auf eine Subdomain beschränkt sind oder vollständig ignoriert werden. Da der Anwendungserver nur nach einem bestimmten Cookie-Namen sucht, wenn er feststellt, ob der Benutzer authentifiziert ist oder ein CSRF-Token korrekt ist, wirkt dies effektiv als Verteidigungsmaßnahme gegen Session Fixation.

Weitere Informationen zu Cookie-Präfixen und dem aktuellen Stand der Browserunterstützung finden Sie im Präfix-Abschnitt des Set-Cookie-Referenzartikels.

Wie zuvor erwähnt, kann das SameSite-Attribut genutzt werden, um zu kontrollieren, wann Drittanbieter-Cookies gesendet werden, und dies kann dazu beitragen, den Datenschutz der Benutzer zu wahren. Datenschutz ist ein sehr wichtiger Aspekt beim Erstellen von Websites, der bei richtiger Umsetzung das Vertrauen der Benutzer stärken kann. Bei schlechter Umsetzung können Vertrauen und viele weitere Probleme vollständig untergraben werden.

Drittanbieter-Cookies können von Drittanbieter-Inhalten gesetzt werden, die über <iframe>s auf Websites eingebettet sind. Sie haben viele legitime Verwendungen, einschließlich der Weitergabe von Benutzerprofilinformationen, zählen von Anzeigenimpressionen oder das Sammeln von Analysen über verschiedene zusammenhängende Domains.

Allerdings können Drittanbieter-Cookies auch genutzt werden, um gruselige, aufdringliche Benutzererlebnisse zu schaffen. Ein Drittanbieter-Server kann basierend auf Cookies, die ihm von demselben Browser beim Zugriff auf verschiedene Seiten gesendet werden, ein Profil des Browserverlaufs und der Gewohnheiten eines Benutzers erstellen. Das klassische Beispiel ist, wenn Sie auf einer Seite nach Produktinformationen suchen und dann überall im Web von Anzeigen für ähnliche Produkte verfolgt werden.

Browseranbieter wissen, dass Benutzer dieses Verhalten nicht mögen, und haben alle begonnen, Drittanbieter-Cookies standardmäßig zu blockieren oder haben zumindest Pläne in diese Richtung gemacht. Drittanbieter-Cookies (oder einfach nur Tracking-Cookies) können auch durch andere Browsereinstellungen oder Erweiterungen blockiert werden.

Siehe unseren Drittanbieter-Cookies-Artikel für detaillierte Informationen über Drittanbieter-Cookies, die damit zusammenhängenden Probleme und welche Alternativen verfügbar sind. Besuchen Sie unsere Datenschutz-Seite für mehr Informationen über Datenschutz im Allgemeinen.

Gesetzgebung oder Vorschriften, die die Verwendung von Cookies betreffen, umfassen:

• Die Datenschutz-Grundverordnung (GDPR) in der Europäischen Union
• Die Datenschutzrichtlinie für elektronische Kommunikation in der EU
• Das kalifornische Verbraucherschutzgesetz

Diese Vorschriften haben globale Reichweite. Sie gelten für jede Website im World Wide Web, die von Benutzern aus diesen Rechtsordnungen aufgerufen wird (die EU und Kalifornien, mit dem Vorbehalt, dass das Gesetz in Kalifornien nur auf Unternehmen mit einem Bruttoumsatz von über 25 Millionen USD gilt, unter anderem).

Diese Vorschriften umfassen Anforderungen wie:

• Benutzer informieren, dass Ihre Website Cookies verwendet.
• Benutzern die Möglichkeit geben, den Empfang einiger oder aller Cookies abzulehnen.
• Benutzern erlauben, den Großteil Ihres Dienstes ohne den Empfang von Cookies zu nutzen.

Es könnte andere Vorschriften geben, die die Verwendung von Cookies in Ihrem Gebiet regeln. Die Verantwortung liegt bei Ihnen, diese Vorschriften zu kennen und einzuhalten. Es gibt Unternehmen, die "Cookie-Banner"-Code anbieten, der Ihnen hilft, diesen Vorschriften zu entsprechen.

• Verwandte HTTP-Header: Set-Cookie, Cookie
• Verwandte JavaScript-APIs: Document.cookie, Navigator.cookieEnabled, Cookie Store API
• Drittanbieter-Cookies
• Cookie-Spezifikation: RFC 6265
• Cookies, die DSGVO und die Datenschutzrichtlinie für elektronische Kommunikation