HTTP-Cookie

Grundidee und Zweck

Ein HTTP-Cookie ist eine Textinformation, die eine Website im Browser auf dem Computer des Benutzers speichern kann. Meist erzeugt ein Webserver das Cookie und sendet es über das Hypertext Transfer Protocol (HTTP) an den Browser. Der Browser verwaltet es und übermittelt es bei späteren passenden Seitenaufrufen wieder an den Server, solange es nicht gelöscht oder ungültig wird. Cookies können außerdem durch JavaScript in einer Webseite erzeugt und ausgelesen werden.

Cookies sind wichtig, weil HTTP ein zustandsloses Protokoll ist: Für den Server sind einzelne Seitenaufrufe zunächst unabhängig voneinander. Ein Cookie kann deshalb einen eindeutigen Sitzungsbezeichner enthalten. Dieser ordnet den Browser einer auf dem Server gespeicherten Sitzung zu. So bleiben beispielsweise ein Login, persönliche Einstellungen oder ein Warenkorb über mehrere Seitenaufrufe erhalten. Beim Electronic Banking wird aus Sicherheitsgründen eher ein Einmal-Token pro Seitenaufruf eingesetzt.

Weitere Anwendungen sind das lokale Speichern von Einstellungen und das Zwischenspeichern von Eingaben bei unterbrochenen Verbindungen, etwa in Mobilfunknetzen. Nach Wiederherstellung der Verbindung kann der Server die zwischengespeicherten Daten abfragen. Da dabei viele Cookies entstehen können und der Speicher begrenzt ist, muss die Webanwendung einen Cookie-Überlauf verhindern.

Cookies können auch zur Analyse des Nutzungsverhaltens und für Werbung verwendet werden. Dafür ist die Einwilligung des Nutzers erforderlich. Im Datenschutz wird der Begriff Cookie teilweise weiter gefasst und auch für Datenentnahme, -speicherung, -nutzung, -weitergabe oder -missbrauch verwendet, selbst wenn technisch kein HTTP-Cookie eingesetzt wird.

Aufbau, Grenzen und Übertragung

Ein Cookie besteht aus einem Namen und einem Wert; zusätzlich können Attribute seine Gültigkeit und Behandlung bestimmen. Grundformen der HTTP-Kopfzeilen sind:

Set-Cookie: Name=Wert; Attribut

Cookie: Name=Wert; Name=Wert

Name und Wert bestehen aus druckbaren US-ASCII-Zeichen, wobei bestimmte Zeichen ausgeschlossen sind. Im Wert sind unter anderem Semikolon, Komma, Leerraum und Backslash nicht unmittelbar zulässig. Beliebige Daten können beispielsweise mit Base64 oder durch URL-Kodierung als %xx dargestellt werden.

Das Attribut HttpOnly verhindert bei unterstützenden Browsern den Zugriff durch JavaScript. Es kann dadurch einen gewissen Schutz gegen Cross-Site-Scripting bieten. Secure bedeutet, dass ein Cookie nur über eine sichere HTTPS-Verbindung an den Server gesendet werden darf. Domain und Path schränken die Gültigkeit auf eine Domain beziehungsweise einen Verzeichnispfad ein. Attribute wie Expires oder Max-Age legen die Lebensdauer fest.

Nach RFC 6265 soll ein Browser mindestens folgende Größen unterstützen:

• mindestens 4096 Bytes pro Cookie,
• mindestens 50 Cookies pro Domain,
• insgesamt mindestens 3000 Cookies.

Größere Werte sind erlaubt. Für möglichst breite Browser-Kompatibilität sollte ein Cookie 4 Kilobyte, also 4 · 1024 Byte, nicht überschreiten.

Cookies können über HTTP-Kopfzeilen oder lokal durch JavaScript und andere Skriptsprachen erzeugt werden. Der Browser speichert sie üblicherweise in einer Cookie-Datenbank. Bei einem Zugriff sucht er die Cookies heraus, deren Domain und Pfad zum Ziel passen, und sendet sie im HTTP-Header mit. Cookies derselben Domain können lokal gelesen, ausgewertet und verändert werden; andere Websites dürfen nicht einfach darauf zugreifen.

Cookies werden mit jeder passenden Datei-Anfrage übertragen, auch bei Bildern, Werbebannern oder anderen eingebetteten Elementen. Da solche Elemente von unterschiedlichen Servern stammen können, kann eine Webseite Cookies mehrerer Anbieter auslösen. Die Verwaltung liegt beim Client: Der Browser entscheidet, ob er ein Cookie speichert und wann er es löscht. Der Server erfährt erst durch spätere HTTP-Anfragen, ob das Cookie angenommen wurde.

Typisches Beispiel

Eine Suchseite soll sich auch nach dem Schließen des Browsers an den letzten Suchbegriff „cookie aufbau“ erinnern. Beim ersten Aufruf sendet der Browser beispielsweise:

GET /cgi/suche.py?q=cookie+aufbau HTTP/1.0

Der Server antwortet mit dem Suchergebnis und setzt ein Cookie:

Set-Cookie: letzteSuche=Y29va2llIGF1ZmJhdQ==; expires=Tue, 29-Mar-2014 19:30:42 GMT; Max-Age=2592000; Path=/cgi/suche.py

Der Name des Cookies lautet letzteSuche. Der Suchbegriff ist wegen seines Leerzeichens Base64-kodiert. Expires nennt als festen Ablaufzeitpunkt den 29. März 2014. Max-Age=2592000 begrenzt die Gültigkeit zusätzlich auf 30 Tage. Path=/cgi/suche.py sorgt dafür, dass das Cookie nur an die Suchfunktion und nicht an andere Bereiche der Website gesendet wird.

Bei einem Onlineshop wird normalerweise nicht der gesamte Warenkorb im Cookie gespeichert. Stattdessen enthält das Cookie die Identifikation des Warenkorbs oder der Sitzung. Die Artikel-Kennungen ordnet der Webserver dieser Sitzung zu und wertet sie bei der Bestellung aus.

Tracking, Gefahren und Schutz

Die Wiedererkennung eines Browsers kann zum Tracking, also zur Verfolgung des Surfverhaltens, verwendet werden. Ein Anbieter kann innerhalb seiner eigenen Website Nutzungsdaten sammeln und sie gegebenenfalls mit dem Namen eines Kunden verbinden. Für eine Verfolgung über mehrere Websites werden häufig Komponenten eines Tracking-Anbieters eingebunden, etwa Skripte, Bilder, Banner, Zählpixel oder Schriften. Beim Laden erzeugen sie Anfragen an dessen Server.

Cookies eines solchen Dritten heißen Third-Party-Cookies. Dienen sie der Verfolgung, werden sie auch Tracking-Cookies genannt. Der Anbieter kann Besuche verschiedener angeschlossener Websites demselben Nutzer zuordnen und daraus Interessen ableiten. Drittanbieter-Cookies erleichtern dieses Verfahren, sind aber nicht zwingend erforderlich. Andere Identitätsverfahren wie Fingerprinting benötigen keine Cookies; Informationen können auch als Parameter eingebundener Komponenten übertragen werden. Das vollständige Abschalten von Cookies verhindert Tracking daher nicht sicher.

Eine Studie der Universität Berkeley fand 2011 beim Besuch der TOP100-Websites ohne Logins oder Bestellungen 5675 Cookies. Davon stammten 4914 von Dritten; Daten gingen an mehr als 600 Server. Google-Cookies kamen auf 97 % der untersuchten populären Websites vor. Eine Studie der Universität Leuven zeigte 2014, dass bereits 44 Trackingdienste mehr als 40 % des Surfverhaltens verfolgen konnten, obwohl Drittanbieter-Cookies blockiert und nur First-Party-Cookies zugelassen wurden. Trackingdienste setzen Cookies zunehmend im First-Party-Kontext, etwa durch DNS-Aliase, direkt eingebundenen Code oder eine als URL-Parameter übertragene Kennung.

Tracking-Cookies wurden auch von NSA und GCHQ zur Identifikation von Internetnutzern verwendet. Zielpersonen konnten anhand langlebiger Cookies verfolgt und bei einer über zwei Wochen stabilen Identifikation mit Foxit Acid gezielt angegriffen werden.

Auf gemeinsam genutzten Rechnern, etwa in Schulen oder Internet-Cafés, kann ein noch gültiges Sitzungs-Cookie dem nächsten Nutzer Zugang zur vorherigen Sitzung geben. Deshalb sollten Nutzer vor dem Beenden des Browsers alle Cookies löschen oder eine entsprechende automatische Einstellung verwenden.

Browser bieten dafür mehrere Möglichkeiten: Cookies vollständig ablehnen oder nur für bestimmte Domains erlauben, Drittanbieter-Cookies beschränken, bei jedem Cookie nachfragen, Cookies nur bis zum Sitzungsende behalten sowie einzelne oder alle Cookies anzeigen, verändern oder löschen. Als Kompromiss können Sitzungs-Cookies automatisch erlaubt, persistente Cookies dagegen abgelehnt oder nur nach Rückfrage angenommen werden. Whitelists erlauben ausgewählte Domains; andere Cookies können beim Schließen eines Tabs, Fensters oder des Browsers automatisch gelöscht werden.

Spezifikationen und Entwicklung

Netscape Communications entwickelte das Konzept und setzte es 1994 im Netscape Navigator ein. Die IETF begann 1995 mit einer Standardisierung. RFC 2109 erschien 1997, RFC 2965 im Jahr 2000. Weil RFC 2965 keine durchgehende Verbreitung fand, ersetzte RFC 6265 im Jahr 2011 beide Standards, beschrieb die tatsächlich verbreitete Funktionsweise und erklärte Set-Cookie2 für veraltet. RFC 6265 spezifizierte auch HttpOnly, das Microsoft bereits 2002 mit Internet Explorer 6 eingeführt hatte.

Nach der Netscape-Spezifikation enthält Set-Cookie ein Name-Wert-Paar und optionale Attribute. Expires gibt ein Verfallsdatum im Format Wdy, DD-Mon-YY HH:MM:SS GMT an. Fehlt es, wird das Cookie beim Schließen des Browsers gelöscht. Domain beschränkt die Gültigkeit auf eine Domain und deren darunterliegende Domains; ohne Angabe gilt die aktuelle Domain. Path setzt ein gültiges Pfadpräfix, Secure beschränkt die Übertragung auf HTTPS.

RFC 2109 erlaubt im Wert auch Semikola, Kommata und Leerzeichen, sofern der Wert in Anführungszeichen steht. Ein Name darf nicht mit $ beginnen, weil dieses Zeichen Attribute in Cookie-Anfragen kennzeichnet. Max-Age ersetzt Expires und gibt die Gültigkeitsdauer in Sekunden an; 0 fordert die sofortige Löschung. Der Client darf das Cookie dennoch länger verwenden, weshalb sich der Server nicht sicher auf die Löschung verlassen kann. Neu waren außerdem Comment und das notwendige Attribut Version, das in dieser Spezifikation immer den Wert 1 hat.

RFC 2965 verwendet Set-Cookie2 statt Set-Cookie. Hinzu kommen CommentURL für eine Adresse mit einer Beschreibung, Discard für die unbedingte Löschung beim Beenden des Browsers und Port zur Beschränkung auf den aktuellen Port oder eine Portliste. Auch hier ist Version notwendig und hat den Wert 1.

Datenschutz und Einwilligung

Cookies können nützliche Funktionen ermöglichen, aber auch eine eindeutige Identifikation und umfangreiche Nutzerprofile unterstützen. Ein bewusster Umgang soll die informationelle Selbstbestimmung schützen. Nutzer können gesetzte Cookies in Browser oder Betriebssystem finden und löschen sowie das automatische Akzeptieren einschränken. Nur wenige Seitenfunktionen schreiben Cookies zwingend vor, beispielsweise die Anmeldung bei Wikipedia.

Seit dem 19. Dezember 2009 gilt die Richtlinie 2009/136/EG, die als Cookie-Richtlinie bezeichnet wird. Sie verlangt eine Einwilligung des Webseitenbenutzers in die Nutzung personenbezogener Daten, wurde von den EU-Staaten jedoch unterschiedlich umgesetzt. Ein von der Opposition unterstützter SPD-Entwurf zur Änderung des deutschen Telemediengesetzes wurde am 18. Oktober 2012 im Bundestag abgelehnt. In Österreich erfolgte die Umsetzung in § 165 Telekommunikationsgesetz 2021.

Die Datenschutz-Grundverordnung trat im Mai 2018 in Kraft. Eine ergänzende e-Privacy-Verordnung war zu diesem Zeitpunkt noch nicht abgeschlossen; der Text nennt dazu den Stand September 2018. Am 1. Oktober 2019 entschied der Europäische Gerichtshof, dass das Setzen und Abrufen von Cookies durch Internetseiten eine aktive Einwilligung des Besuchers erfordert.

Im Mai 2020 wurde über eine Entscheidung des deutschen Bundesgerichtshofs berichtet, nach der Nutzer ihre Zustimmung zu Cookies ebenfalls aktiv geben müssen. Die Richter folgten weitgehend dem EuGH-Urteil vom Oktober 2019: Vorausgefüllte Cookie-Banner sind nicht mit europäischem Recht vereinbar. Damit genügt es nicht, wenn Nutzer dem Tracking erst aktiv widersprechen müssen; erforderlich ist grundsätzlich ein Opt-in, also eine vorherige ausdrückliche Zustimmung.