Clear-Site-Data: Browserdaten bewusst bereinigen

Drei getrennte Aufgaben beim Abmelden

Ein wirksamer Logout kann drei Aufgaben haben: serverseitige Sitzung beziehungsweise maßgebliche Tokens beenden, browserseitige Zugangsdaten entfernen und verbleibende persönliche Anwendungsdaten bereinigen. Clear-Site-Data betrifft die Browserseite. Ein gelöschtes Cookie macht ein kopiertes, serverseitig weiterhin gültiges Token nicht automatisch ungültig. Umgekehrt macht übrig gebliebener Local Storage eine korrekt invalidierte Sitzung nicht wieder gültig. Clear Site Data: Anwendungsfälle und Grenzen

Der Web Security Check liest den Header der final abgerufenen Antwort. Er führt keinen Logout aus und beobachtet keine Löschung im Browser. Auf einer gewöhnlichen Inhaltsseite kann der fehlende Header völlig angemessen sein. Auch „keine Session-Cookies in dieser Antwort erkannt“ beweist weder eine Website ohne Login noch fehlenden Anwendungsstorage.

Verbleibende Daten auf einem gemeinsamen Gerät

Ein Konto kann abgemeldet sein, während die Anwendung zuvor Profilinformationen in Local Storage, IndexedDB oder Offlinecaches hinterlegt hat. Die nächste Person im selben Browserprofil könnte diese Daten je nach Anwendung weiterhin finden. Das ist ein möglicher Datenrest, keine automatisch wiederhergestellte Sitzung und kein Beweis, dass jeder Logout ohne diesen Header unsicher ist.

Das zu prüfende Szenario lautet: Anwendung speichert synthetische persönliche Daten → Logout beendet den Serverzugriff → Browserbereinigung entfernt die vorgesehenen Daten → alter Tab, Zurücknavigation und erneuter Zugriff werden geprüft. Aktive Dokumente können noch Daten im Speicher halten oder neu schreiben; eine einzelne Löschanweisung ist keine dauerhafte Zugriffssperre.

Datenarten und Reichweite

Die Werte sind Zeichenketten in doppelten Anführungszeichen. Clear-Site-Data: storage ist keine korrekte Schreibweise für Clear-Site-Data: "storage". Verwenden Sie die Schreibweise aus der Spezifikation und keine beliebig kombinierten Namen.

Clear Site Data §§ 3–4 beschreibt die Mechanismen, enthält aber auch offene Spezifikationsfragen und historische Speicherarten. Für den Betrieb zählt zusätzlich die Unterstützung je Datenart.

Die lokale Chromium-Probe verdeutlicht die Reichweite: "cookies" entfernte auch ein Cookie der benachbarten Subdomain. "storage" entfernte die geprüften Speicher der antwortenden Origin, während Local Storage der Nachbarorigin erhalten blieb. Ein in derselben Antwort gesetztes Cookie wurde bei "cookies" ebenfalls entfernt. Ein für die nächste Seite benötigtes Hinweiscookie sollte deshalb nicht ungeprüft in dieselbe Löschantwort eingebaut werden.

Unterstützung pro Direktive beurteilen

Die am 27.09.2026 gelesenen Kompatibilitätsdaten nennen grundlegende Unterstützung ab Chrome 61, Firefox 63 und Safari 17. Daraus folgt keine identische Wirkung aller Werte:

• Für Firefox ist "cache" von Version 63 bis vor 94 und wieder ab 138 dokumentiert.
• Chromium hat für "cache" und "*" dokumentierte Einschränkungen, unter anderem zu wiederverwendeten Antworten im vorhandenen Tab und möglichen Verzögerungen.
• "executionContexts" ist keine verlässliche aktuelle Funktion über die Engines hinweg. Der Entwurf beschreibt das Neuinitialisieren aktiver Kontexte, die Kompatibilitätsdaten zeigen fehlende beziehungsweise wieder entfernte Implementierungen.
• Neuere Werte wie "clientHints", "prefetchCache" und "prerenderCache" sind keine universellen Grundfunktionen. Verlassen Sie sich dafür nicht auf die Unterstützung von "cookies" oder "storage".

Öffentliche Anwendungen sollten die Bereinigungsantwort über HTTPS liefern. Browser verlangen einen entsprechend vertrauenswürdigen Kontext; lokale Loopback-Ausnahmen in einer Entwicklungsprobe rechtfertigen kein öffentliches HTTP-Rezept.

Ein JavaScript-Fallback ist nur ergänzend: Er kann bekannte eigene Speicher gezielt bereinigen, aber nicht etwa HttpOnly-Cookies über document.cookie entfernen oder jeden Browsercache leeren. Asynchrone IndexedDB-/Cache-/Service-Worker-Aktionen müssen abgewartet und Fehler beziehungsweise offene Verbindungen behandelt werden. Ein pauschales localStorage.clear() kann zudem Daten anderer Funktionen derselben Origin entfernen. Ein universelles „löscht alles“-Skript wäre deshalb irreführend.

Einen Logout mit begrenztem Löschumfang gestalten

Zuerst legt die Anwendung fest, was ein Logout bedeutet: nur diese Sitzung, alle Sitzungen, Wechsel des Kontos oder zusätzlich Entfernen von Offlineinhalten. Invalidieren beziehungsweise widerrufen Sie die dafür maßgeblichen serverseitigen Berechtigungen und Tokens nach der tatsächlichen Sitzungsarchitektur. Das erfordert nicht in jedem System dieselbe Datenbankoperation.

Danach kann eine Antwort etwa so aussehen, wenn die Storage-Bereinigung dieser Origin gewollt ist und die Sitzungs-Cookies gesondert korrekt entfernt werden:

HTTP/1.1 303 See Other
Location: /abgemeldet/
Cache-Control: no-store
Clear-Site-Data: "storage"

Für einen Ablauf, der bewusst auch den breiteren Cookiebereich und Netzwerkcache bereinigen soll, kommt stattdessen Clear-Site-Data: "cache", "cookies", "storage" infrage. Das ist eine andere Entscheidung mit größerem Funktionsverlust, keine automatisch bessere Bewertung. Bei Passwort- oder Accountänderungen ist die gewünschte Behandlung anderer Sitzungen und lokaler Daten gesondert festzulegen.

Ein zustandsändernder Logout gehört gewöhnlich in einen dafür geschützten POST-Ablauf. POST allein ist kein CSRF-Schutz; die bestehende Anwendung muss die erforderliche Requestprüfung leisten. Der Browser muss die tatsächliche Antwort erhalten. Eine Weiterleitung ist möglich, beseitigt aber nicht die Notwendigkeit, Header auf der richtigen Antwort zu liefern.

Wird ein Logout per Fetch aufgerufen, prüfen Sie Credentials-Modus und Netzwerkkette. Im lokalen Test wirkte eine Same-Origin-Bereinigungsantwort mit dem normalen Credentials-Modus; bei credentials: "omit" blieb die Bereinigung aus. Eine vom Service Worker nur synthetisch erzeugte Antwort mit demselben Header wirkte ebenfalls nicht, eine durchgereichte Netzwerkantwort dagegen schon. Der Entwurf begrenzt die Verarbeitung bewusst auf Netzwerkantworten. Clear Site Data § 5.2

Erfolg am verbleibenden Zustand erkennen

Prüfen Sie mit synthetischen Daten vor und nach dem Ablauf:

1. Serverzugriffe mit der bisherigen Sitzung beziehungsweise dem alten Token werden nach dem vorgesehenen Logoutumfang abgewiesen.
2. Die gewollten Cookies und Speicher sind tatsächlich entfernt; andere Anwendungen auf Subdomains funktionieren gemäß der bewusst gewählten Reichweite weiter.
3. Alter und neuer Tab, Zurück-/Vorwärtsnavigation, Offlineansicht und Service Worker zeigen keine unerwünschten persönlichen Daten. HTTP-Cache und bfcache sind unterschiedliche Mechanismen.
4. Der Ablauf funktioniert auch im Zielbrowser, der eine gewünschte Direktive nicht unterstützt. Logout muss serverseitig wirksam bleiben.

Beim Rückweg stoppen Sie die Löschanweisung an der zuständigen Ausgabestelle, stellen nötige Anmeldung und Offlinefunktionen wieder her und prüfen betroffene Tabs. Bereits gelöschte lokale Daten werden dadurch nicht rekonstruiert.

Kein Nachweis vollständiger Datenlöschung

Der Header löscht keine Serverdaten, Backups, Protokolle, bereits exportierten Dateien oder Informationen außerhalb seines Browser-/Originbereichs. Auch Datenträgerreste sind keine zugesicherte vollständige Löschung. Daraus entsteht kein alleiniger DSGVO-, PCI- oder NIS2-Erfüllungsnachweis. Clear Site Data § 6.2, Compliance-Übersicht