Cookie-Prüfer

Nein, und nichts im Web kann das sein. Eine Seite darf nur Cookies lesen, die zu ihrer eigenen Adresse gehören — genau diese Beschränkung ist der ganze Grund, warum Cookies sicher sind, denn sonst könnte jede Seite die Ihrer Bank lesen. Um Cookies zu sehen, die Ihr Browser schon hält, brauchen Sie dessen eigene Einstellungen oder Entwicklerwerkzeuge oder eine Erweiterung, der Sie das erlaubt haben. Dies ist ein Betrachter für das, was eine Seite zurückschickt — eine andere Frage, und die, die Sie von hier aus beantworten können.

Weil er eine Seite einmal abfragt, als Besucher, der nie da war. Viele Cookies werden später gesetzt — von JavaScript nach dem Laden, von einem Drittanbieterskript oder erst, wenn jemand ein Zustimmungsbanner annimmt. Nichts davon steht in einer ersten Antwort. Nehmen Sie, was Sie hier sehen, als die Cookies, die eine Seite setzt, bevor Sie irgendetwas zugestimmt haben — die interessante Zahl für eine Datenschutzprüfung, nicht die Gesamtzahl.

Fragen Sie sie nach einer Seite und lesen Sie, was zurückkommt — genau das tut dies: Adresse eingeben, um Cookies auf Website-Seiten zu prüfen, die Ihnen nicht gehören, und Sie bekommen jedes Cookie dieser ersten Antwort mit Domain, Ablauf und Schaltern. Es ist dasselbe, was ein Browser tut, bevor er irgendetwas darstellt, nur ohne das Darstellen. Nicht zeigen kann er, was später von JavaScript oder nach einem Zustimmungsbanner gesetzt wird: Nehmen Sie es also als das, was eine Seite setzt, bevor Sie zugestimmt haben, und nicht als vollständige Liste.

Secure verhindert, dass das Cookie über einfaches HTTP gesendet wird, damit es niemand mitlesen kann, der die Verbindung beobachtet. HttpOnly verbirgt es vor JavaScript, sodass ein Cross-Site-Scripting-Fehler es nicht stehlen kann — bei einem Anmelde-Cookie zählt das am meisten. SameSite steuert, ob das Cookie bei Anfragen mitfährt, die andere Seiten starten: Strict nie, Lax nur bei gewöhnlichen Linkklicks, None immer, was dann Secure voraussetzt. Fehlendes SameSite behandeln aktuelle Browser als Lax, aber es hinzuschreiben ist besser, als sich auf eine Vorgabe zu verlassen, die sich schon einmal geändert hat.

Nein. Ein Cookie, das JavaScript lesen soll — eine Themenwahl, ein weggeklicktes Banner, eine Sprache — muss für JavaScript lesbar sein, HttpOnly würde es also kaputtmachen. Der Schalter zählt bei allem, was Sie identifiziert: eine Sitzungs-ID, ein Anmeldetoken, ein an ein Konto gebundener Warenkorb. Dieses Werkzeug sagt, welche Schalter fehlen und wovor jeder schützt; ob das wichtig ist, hängt davon ab, wozu das Cookie dient, und das weiß nur die Seite selbst.

Sie sieht eine gewöhnliche Seitenanfrage von unserem Server, nicht von Ihnen. Ihre Adresse wird nicht weitergegeben, und kein Cookie wird gespeichert, gesendet oder wiederverwendet — die Antwort wird einmal gelesen und verworfen. Fügen Sie statt einer Adresse einen Set-Cookie-Header ein, wird überhaupt nichts abgerufen und die ganze Prüfung geschieht, ohne diese Seite zu verlassen.

Alles, was keine gewöhnliche öffentliche Webadresse ist: lokale Namen wie localhost, Adressen in privaten Netzen und alles, was nicht http oder https ist. Ein Werkzeug, das abruft, was man ihm gibt, ließe sich auf Maschinen richten, die nur unser Server erreicht; also lehnt es die rundheraus ab und sagt es — auch dann, wenn eine Weiterleitung es irgendwohin Privates führen will.

Das ist Sache Ihres Browsers, nicht einer Seite — keine Website kann die Cookies einer anderen löschen. In Chrome und Edge: Einstellungen, Datenschutz und Sicherheit, Drittanbieter-Cookies, dann Alle Websitedaten und Berechtigungen anzeigen; in Firefox: Einstellungen, Datenschutz & Sicherheit, Cookies und Website-Daten, Daten verwalten; in Safari: Einstellungen, Datenschutz, Website-Daten verwalten. Überall lässt sich eine einzelne Seite entfernen statt alles, und das ist meist gewollt — alles zu löschen meldet Sie überall ab.