Wann darf ein Zwischenspeicher eine Seite mit Cookie weitergeben?

Eine weitergegebene Seite kann eine Meldepflicht auslösen

Sieht ein Besucher die persönlichen Daten eines anderen, kann das nach der DSGVO eine Verletzung des Schutzes personenbezogener Daten sein, auch wenn sie unbeabsichtigt geschah (Art. 4 Nr. 12). Der Verantwortliche meldet sie unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde, außer es besteht voraussichtlich kein Risiko für die Betroffenen (Art. 33). Ob das für Ihren Fall gilt, klärt Ihr Datenschutzbeauftragter. Was in den ersten Stunden zu tun ist, steht auf der Seite „Ein Kunde sieht fremde Daten auf Ihrer Website: wie gehen Sie vor?“.

Bei Steam sahen Kunden fremde Adressen und Bestellungen

Am 25. Dezember 2015 lieferte der Spieleladen Steam Seiten angemeldeter Kunden an andere Besucher aus. Während eines Angriffs mit extrem vielen Anfragen hatte ein Dienstleister die Zwischenspeicherung umgestellt, und die zweite Einstellung speicherte auch Seiten angemeldeter Kunden. Zwischen 11:50 und 13:20 Uhr pazifischer Zeit konnten Anfragen von rund 34.000 Kunden betroffen sein. Auf manchen Seiten standen Rechnungsadresse, Kaufverlauf und E-Mail-Adresse. Anmelden oder kaufen konnte damit laut Valve niemand.

public erlaubt jedem Zwischenspeicher die Weitergabe

Cache-Control: public bedeutet, dass jeder Zwischenspeicher auf dem Weg die Antwort aufbewahren und weiteren Besuchern ausliefern darf. Das ist richtig für Seiten, die für alle gleich sind, und macht sie schnell. Setzt die Antwort aber ein Cookie, etwa die Kennung einer Sitzung, kann der Zwischenspeicher dieses Cookie mit an den nächsten Besucher geben. Der bekommt dann die Sitzung eines anderen: einen fremden Warenkorb, im ungünstigen Fall eine fremde Anmeldung oder persönliche Daten auf der Seite. Ob es so weit kommt, hängt vom Zwischenspeicher ab; viele lassen Antworten mit Cookie von sich aus aus, verlassen kann man sich darauf nicht.

Gemessen werden Set-Cookie und Cache-Control derselben Antwort

Die Prüfung liest in der Antwort jeder Seite des Laufs die Kopfzeilen Set-Cookie und Cache-Control. Setzt die Antwort mindestens ein Cookie und steht in Cache-Control public, ohne private oder no-store, nennt der Bericht die Seite und zeigt beide Kopfzeilen, wie Ihr Server sie geschickt hat. Weil hier fremde Sitzungen auf dem Spiel stehen, ordnet die Prüfung den Befund als schwerwiegend ein.

Privat, was persönlich ist, öffentlich nur ohne Cookie

Antworten, die ein Cookie setzen oder persönliche Inhalte zeigen, enthalten Cache-Control: private oder no-store. private erlaubt nur dem Browser des Besuchers, die Antwort aufzubewahren; no-store verbietet das Aufbewahren ganz. public bleibt für Seiten, die für alle gleich sind und kein Cookie setzen. Oft ist das Cookie auf einer öffentlichen Seite gar nicht nötig: setzt die Website eine Sitzung erst, wenn jemand sich anmeldet oder etwas in den Warenkorb legt, bleiben die übrigen Seiten öffentlich speicherbar und schnell. Zusätzlich lässt sich das Content Delivery Network so einstellen, dass es Antworten mit Set-Cookie nie aufbewahrt.

Tipps aus der Praxis

• no-store hat einen Preis: Der Browser verliert laut MDN auch den Speicher für den Zurück-Knopf. Für persönliche Seiten ohne sensible Daten empfiehlt MDN no-cache zusammen mit private.
• Schlägt jemand Vary: Cookie als Lösung vor, verweisen Sie auf MDN: Für persönliche Inhalte gehört private in die Antwort.
• Testen Sie nach jeder Änderung an Cache-Regeln mit zwei Konten in zwei Browsern: Jedes Konto muss auf Konto- und Warenkorbseite seine eigenen Daten zeigen.

Mehr zu diesem Thema

• Ein Kunde sieht fremde Daten auf Ihrer Website: wie gehen Sie vor?Zeigt Ihre Website einem Kunden fremde Namen oder Bestellungen, schalten Sie zuerst den Zwischenspeicher ab. Danach Belege sichern und die Meldefrist klären.