Clear-Site-Data

Verwendung

Das Ausliefern eines fehlerhaften Assets, das Rotieren von Authentifizierungs-Token oder das Abmelden eines Nutzers erzeugen allesamt Situationen, in denen veraltete clientseitige Daten verschwinden müssen. Nutzer durch ein manuelles Leeren des Caches zu führen, ist unzuverlässig. Der Header Clear-Site-Data gibt dem Server eine deklarative Möglichkeit, bestimmte Kategorien gespeicherter Daten in einer einzigen Antwort zu entfernen.

Der Header akzeptiert eine oder mehrere in Anführungszeichen gesetzte Zeichenketten-Direktiven, die angeben, welche Datentypen gelöscht werden sollen. Mehrere Direktiven werden durch Kommas getrennt. Der Platzhalter ”*” löscht alles, einschließlich der Datentypen, die durch künftige Überarbeitungen der Spezifikation hinzukommen.

Der Header funktioniert ausschließlich über HTTPS. Browser ignorieren den Header bei unsicheren HTTP-Antworten. Der Geltungsbereich von “cookies” erstreckt sich auf die gesamte registrierte Domain und alle Subdomains, das heißt eine Clear-Site-Data-Antwort von example.re löscht auch Cookies, die von stage.example.re gesetzt wurden.

Ein verbreitetes Deployment-Muster ist es, den Header an einen Logout-Endpunkt anzuhängen. Der Server beantwortet die Abmeldeanfrage mit Clear-Site-Data, um Session-Cookies, zwischengespeicherte Ressourcen und den lokalen Speicher in einem Durchgang zu löschen. Ein weiteres Muster ist eine eigens dafür vorgesehene Cache-Busting-URL, die nach einem fehlerhaften Deployment vorübergehend ausgeliefert wird und es Betreibern erlaubt, Besucher auf frische Assets zu zwingen, ohne das Ablaufen des Caches abzuwarten.

Hinweis

Clear-Site-Data bei jeder Antwort zu senden, deaktiviert das Caching für die Website faktisch vollständig. Jeder Seitenaufruf leert den Browser-Cache und verursacht spürbare Leistungseinbußen. Beschränken Sie den Header auf gezielte Antworten wie Logout-Endpunkte, Fehlerbehebungsseiten oder temporäre Cache-Busting-URLs.

Hinweis

Alle großen Browser unterstützen den Header Clear-Site-Data. Safari unterstützt alle Direktiven außer “executionContexts” und erzwingt eine Origin-Partitionierung, die verhindert, dass ein Cross-Site-iframe First-Party-Daten löscht.

”cache”

Löscht den HTTP-Cache des Browsers für den Origin. Bestimmte Implementierungen löschen auch zugehörige Caches, darunter vorgerenderte Seiten, Einträge im Vor-/Zurück-Cache, Skript-Caches, WebGL-Shader-Caches und Vorschläge der Adressleiste.

”cookies”

Löscht alle Cookies der registrierten Domain und aller Subdomains. Löscht außerdem die mit dem Origin verknüpften HTTP-Authentifizierungsdaten. Der Geltungsbereich ist breiter als bei den anderen Direktiven, weil der Domain-Abgleich bei Cookies übergeordnete und gleichrangige Subdomains einschließt.

”storage”

Löscht den DOM-Speicher für den Origin. Dazu zählen localStorage, sessionStorage, IndexedDB-Datenbanken, Service-Worker-Registrierungen, Web-SQL-Datenbanken (veraltet), Daten der FileSystem API und Plugin-Daten.

”executionContexts”

Lädt alle Browsing-Kontexte des Origins neu. Der Browser führt in jedem offenen Tab und jedem Frame, der mit dem Origin verknüpft ist, das Äquivalent von location.reload() aus. Diese Direktive ist experimentell und nicht breit implementiert.

Chromium-spezifische Erweiterungen

Die Direktiven “clientHints”, “prefetchCache” und “prerenderCache” sind Chromium-spezifische Erweiterungen, die in der W3C-Spezifikation Clear Site Data nicht definiert sind. Die von der Spezifikation definierten Direktiven sind “cache”, “cookies”, “storage”, “executionContexts” und ”*”. Die Chromium-Erweiterungen funktionieren nur in Chromium-basierten Browsern und werden von Firefox oder Safari nicht erkannt.

”clientHints”

Löscht gespeicherte Client-Hint-Einstellungen, die über den Header Accept-CH gesetzt wurden. Chromium-spezifische Erweiterung. Das Löschen von “cache”, “cookies” oder ”*” löscht auch die Client Hints automatisch.

”prefetchCache”

Löscht die Prefetch-Caches der Speculation Rules, deren Geltungsbereich auf den Referrer-Origin beschränkt ist. Chromium-spezifische Erweiterung. Nützlich, um veraltete vorab abgerufene Inhalte nach einer Zustandsänderung wie einer An- oder Abmeldung zu verwerfen. Der Header mit dieser Direktive wirkt bei jeder Same-Site-HTTP-Antwort.

”prerenderCache”

Löscht die Prerender-Caches der Speculation Rules, deren Geltungsbereich auf den Referrer-Origin beschränkt ist. Chromium-spezifische Erweiterung. In Kombination mit “prefetchCache” lassen sich alle Caches des spekulativen Ladens leeren. Eine clientseitig gerenderte Anwendung, die ihre Daten aus JavaScript bezieht, verwendet “prerenderCache” bei Zustandsänderungen, um vorgerenderte Seiten zu verwerfen und das vorab abgerufene HTML dabei unangetastet zu lassen.

”*” (Platzhalter)

Löscht alle Datentypen des Origins, einschließlich aller künftigen Direktiventypen, die der Spezifikation hinzugefügt werden. Die sicherste Wahl für eine vollständige Bereinigung, mit der breitesten Auswirkung auf das Surferlebnis.

Beispiel

Ein Logout-Endpunkt löscht Session-Cookies und Speicher. Der Browser löscht alle Cookies der Domain (einschließlich Subdomains), entfernt localStorage- und IndexedDB-Daten und verwirft zwischengespeicherte Ressourcen.

Clear-Site-Data: "cache", "cookies", "storage"

Ein gezieltes Leeren ausschließlich des Caches nach einem fehlerhaften Deployment. Der Server hängt diesen Header vorübergehend an Antworten an, bis die Besucher auf frische Assets gewechselt sind.

Clear-Site-Data: "cache"

Eine vollständige Bereinigung mithilfe des Platzhalters. Sämtliche zwischengespeicherten Daten, Cookies, Speicherinhalte und alle künftigen Datentypen werden entfernt. Verbreitet auf Bestätigungsseiten für die Kontolöschung.

Clear-Site-Data: "*"

Nach einer Zustandsänderung werden nur die Caches des spekulativen Ladens geleert. Vorab abgerufene und vorgerenderte Seiten von vor dem Login-Ereignis werden verworfen.

Clear-Site-Data: "prefetchCache", "prerenderCache"