Speicherpartitionierung

Um den Datenschutz für Nutzer zu verbessern und websiteübergreifendes Tracking bei Seitenkanälen zu verhindern, werden in Chrome die meisten Speicher- und Kommunikations-APIs in Drittanbieterkontexten durch eine sogenannte Speicherpartitionierung isoliert.

Implementierungsstatus

Die Funktion ist für alle Nutzer in Chrome 115 und höher aktiviert. Ähnliche Speicherpartitionierungsbemühungen sind auch in anderen gängigen Browsern wie Firefox und Safari vorhanden oder geplant. Der Vorschlag zur Speicherpartitionierung auf GitHub steht für weitere Diskussionen offen.

Was ist die Speicherpartitionierung?

Um bestimmte Arten von websiteübergreifendem Tracking bei Seitenkanälen zu verhindern, partitioniert Chrome Speicher- und Kommunikations-APIs im Zusammenhang mit Drittanbietern.

Ohne Speicherpartitionierung kann eine Website Daten von verschiedenen Websites zusammenführen, um Nutzer im Web zu verfolgen. Außerdem kann die eingebettete Website mithilfe von Side-Channel-Techniken wie Timing-Angriffen, XS-Leaks und COSI bestimmte Status des Nutzers auf der Website der obersten Ebene ableiten.

Bisher wurde der Speicherplatz nur nach Herkunft sortiert. Wenn also ein Iframe von example.com auf a.com und b.com eingebettet ist, kann er Informationen zu Ihren Browsergewohnheiten auf diesen beiden Websites erhalten, indem eine ID gespeichert und erfolgreich aus dem Speicher abgerufen wird. Wenn die Drittanbieter-Speicherpartitionierung aktiviert ist, befindet sich der Speicher für example.com in zwei verschiedenen Partitionen, eine für a.com und die andere für b.com.

Im Allgemeinen bedeutet Partitionierung, dass auf Daten, die von Speicher-APIs wie Local Storage und IndexedDB in einem Iframe geschrieben wurden, nicht mehr von allen Kontexten mit demselben Ursprung zugegriffen werden kann. Stattdessen sind diese Daten jetzt isoliert und nur für Kontexte verfügbar, die denselben Ursprung und dieselbe Website auf oberster Ebene haben.

Vorher

Speicher-APIs ohne Partitionierung
Vor der Speicherpartitionierung kann beispiel.de Daten schreiben, wenn es in a.com eingebettet ist, und sie dann lesen, wenn es in b.com eingebettet ist.

Nachher

Speicher-APIs mit Partitionierung
Nach der Speicherpartitionierung kann „beispiel.de“, wenn es in „b.de“ eingebettet ist, nicht auf den Speicher von „beispiel.de“ zugreifen, wenn es in „a.de“ eingebettet ist.

Speicherpartitionierung in verketteten iFrames

Die Komplexität der Speicherpartitionierung erhöht sich erheblich, wenn Iframes verschachtelt sind, insbesondere wenn dieselbe Quelle mehrmals in der Kette vorkommt.

Beispiel: A1 enthält einen Iframe für B, der einen Iframe für A2 enthält. A1 und A2 befinden sich auf derselben Website. Wenn bei der Partitionierung nur die Website der obersten Ebene und der Ursprung des aktuellen Frames berücksichtigt werden, wird iFrame A2 möglicherweise fälschlicherweise als „eigen“ behandelt, da er sich trotz des websiteübergreifenden iFrames B dazwischen auf derselben Website wie die Website der obersten Ebene (A1) befindet. Dies könnte A2 Sicherheitsrisiken wie Clickjacking aussetzen, wenn A2 standardmäßig Zugriff auf nicht partitionierten Speicher hätte.

Um dies zu beheben, fügt Chrome dem Speicherpartitionsschlüssel ein „Ancestor-Bit“ hinzu. Dieses Bit wird gesetzt, wenn ein Dokument zwischen dem aktuellen iframe und der Website der obersten Ebene von einem anderen (websiteübergreifenden) Ursprung stammt. In diesem Fall ist Website B websiteübergreifend. Das Bit wird also für A2 gesetzt und der Speicher wird von A1 partitioniert.

Wenn die Iframe-Kette ausschließlich aus Kontexten auf derselben Website besteht (z. B. Website A1 mit A2, die dann A3 enthält), wird der Speicherplatz durch das übergeordnete Bit nicht weiter partitioniert. In solchen Fällen bleibt der Speicher gemeinsam genutzt und wird anhand der gemeinsamen Quelle und der Website der obersten Ebene zugeordnet.

Für Websites, die einen nicht partitionierten Zugriff über verkettete iframes benötigen, erprobt Chrome die Erweiterung der Storage Access API, um diesen Anwendungsfall zu ermöglichen. Da die Storage Access API erfordert, dass die geframete Website die API explizit aufruft, wird das Clickjacking-Risiko verringert.

API-Änderungen aufgrund der Partitionierung

APIs, die von der Partitionierung betroffen sind, lassen sich in die folgenden Gruppen unterteilen:

Storage APIs

  • Kontingentsystem
    Mit dem Kontingentsystem wird festgelegt, wie viel Speicherplatz für die Speicherung zugewiesen wird. Das Kontingentsystem verwaltet jede Partition als separaten Bucket, um zu bestimmen, wie viel Speicherplatz zulässig ist und wann er gelöscht wird.
    Die Methode navigator.storage.estimate() liefert jetzt spezifische Informationen zur Speicherpartition. Chrome-spezifische APIs wie window.webkitStorageInfo und navigator.webkitTemporaryStorage wurden eingestellt.
    IndexedDB und Cache-Speicher verwenden das partitionierte Kontingentsystem.
  • Web Storage API
    Die Web Storage API bietet Mechanismen, mit denen Browser Schlüssel/Wert-Paare speichern können. Es gibt zwei Mechanismen: lokaler Speicher und Sitzungsspeicher. Sie werden nicht kontingentverwaltet, sondern dennoch partitioniert.
  • Origin Private File System
    Mit der File System Access API kann eine Website Änderungen direkt in Dateien und Ordnern auf dem Gerät lesen oder speichern, nachdem der Nutzer Zugriff gewährt hat. Mit dem privaten Dateisystem des Ursprungs können private Inhalte direkt auf dem Laufwerk gespeichert werden. Diese Inhalte sind weiterhin für Nutzer zugänglich, aber jetzt partitioniert.
  • Storage Bucket API
    Die Storage Bucket API wird für den Storage Standard entwickelt, der verschiedene Speicher-APIs wie IndexedDB und localStorage mithilfe eines neuen Konzepts namens „Buckets“ zusammenführt. Die in den Buckets gespeicherten Daten und die zugehörigen Metadaten werden partitioniert.
  • Clear-Site-Data-Header
    Wenn der Clear-Site-Data-Header in die Antwort aufgenommen wird, kann ein Server das Löschen der im Browser des Nutzers gespeicherten Daten anfordern. Cache, Cookies und DOM-Speicher können gelöscht werden. Mit der Überschrift wird nur der Speicherplatz innerhalb einer Partition gelöscht.
  • Blob-URL-Speicher
    Eine Blob-URL bietet Zugriff auf einen Blob, ein Objekt mit Rohdaten. Ohne Speicherpartitionierung kann eine Blob-URL, die in einem Drittanbieter-iFrame auf einer Website generiert wurde, in einem iFrame mit demselben Ursprung verwendet werden, der in eine andere Website eingebettet ist. Wenn beispielsweise example.com-iFrames sowohl in a.com als auch in b.com eingebettet sind, kann eine Blob-URL, die im in a.com eingebetteten iFrame generiert wird, ohne Einschränkungen an den in b.com eingebetteten iFrame übergeben und dann von diesem verwendet werden. Ab Chrome 137 (veröffentlicht am 27. Mai 2025) werden Blob-URLs für alle Verwendungen außer Navigationen der obersten Ebene partitioniert. Beispiele für Fälle, die jetzt blockiert werden, sind die Verwendung von partitionenübergreifenden Blob-URLs mit fetch() oder als src-Attributwert für verschiedene HTML-Elemente. Navigationen der obersten Ebene, z. B. das Aufrufen von window.open() oder das Klicken auf einen Link mit target='_blank' zu Blob-URLs, werden nicht blockiert, wenn sie partitionenübergreifend sind. noopener wird jedoch erzwungen, wenn die Website der Blob-URL websiteübergreifend mit der Website der obersten Ebene der Seite ist, auf der die Navigation gestartet wird. Wenn noopener erzwungen wird, kann das Dokument, das die Navigation initiiert, kein Fenster-Handle für das geöffnete Blob-URL-Dokument erhalten. Im vorherigen Beispiel verhindert die Partitionierung, dass der Iframe auf b.com den Inhalt der Blob-URL abruft, er kann ihn aber weiterhin window.open().

Kommunikations-APIs

Neben Speicher-APIs werden auch Kommunikations-APIs partitioniert, die es einem Kontext ermöglichen, über Herkunftsgrenzen hinweg zu kommunizieren. Die Änderungen betreffen hauptsächlich APIs, die die Erkennung anderer Kontexte über Multicasting oder Rendezvous mit demselben Ursprung ermöglichen.

Aufgrund der Partitionierung verhindern die folgenden Kommunikations-APIs, dass iframes von Drittanbietern Daten mit ihren Kontexten mit gleicher Herkunft austauschen:

  • Broadcast-Kanal
    Die Broadcast Channel API ermöglicht die Kommunikation zwischen Browserkontexten (Fenster, Tabs oder iFrames) und Workern desselben Ursprungs.
    Das Verhalten von websiteübergreifenden iframes postMessage() soll nicht geändert werden, da die Beziehung zwischen diesen Kontexten bereits klar definiert ist.
  • SharedWorker
    Die SharedWorker API stellt einen Worker bereit, auf den über Browserkontexte derselben Quelle zugegriffen werden kann.
  • Websperren
    Mit der Web Locks API kann Code, der in einem Tab oder Worker desselben Ursprungs ausgeführt wird, eine Sperre für eine freigegebene Ressource erwerben, während eine bestimmte Arbeit ausgeführt wird.

Service Worker API

Mit der Service Worker API können Websites Aufgaben im Hintergrund ausführen. Websites registrieren Dienstprogramme, die neue Worker-Kontexte erstellen, um auf Ereignisse zu reagieren. Traditionell konnten diese Worker mit jedem Kontext desselben Ursprungs kommunizieren. Da Service Worker jedoch den Zeitpunkt von Navigationsanfragen ändern können, besteht das Risiko von websiteübergreifenden Datenlecks wie Verlaufs-Sniffing.

Aus diesem Grund werden Service Worker, die über einen Drittanbieterkontext registriert sind, jetzt partitioniert.

Erweiterungs-APIs

Erweiterungen sind Programme, mit denen Nutzer ihre Browsernutzung anpassen können.

Erweiterungsseiten (Seiten mit einem chrome-extension://-Schema) können auf Websites im Web eingebettet werden. In diesem Szenario haben die Erweiterungsseiten weiterhin Zugriff auf ihre Partition der obersten Ebene. Erweiterungen können auch andere Websites einbetten. In diesem Fall greifen die eingebetteten Websites auf ihre Partition der obersten Ebene zu, sofern die Erweiterung Hostberechtigungen dafür hat.

Weitere Informationen finden Sie in der Dokumentation zur Erweiterung.

Demo: Speicherpartitionierung testen

Demo-Website: https://storage-partitioning-demo-site-a.glitch.me/

Demo-Website mit grünen Häkchen links und roten Kreuzen rechts
Screenshot der Demo mit der Ausgabe für einen Browser mit Speicherpartitionierung links und ohne Speicherpartitionierung rechts.

In der Demo werden zwei Websites verwendet: Website A und Website B.

  • Wenn Sie Website A im Kontext der obersten Ebene besuchen, werden Daten mit verschiedenen Speichermethoden festgelegt.
  • Auf Website B ist eine Seite von Website A eingebettet. Bei der Einbettung wird versucht, die zuvor festgelegten Speicheroptionen zu lesen.
  • Wenn Website A in Website B eingebettet ist, hat sie keinen Zugriff auf diese Daten, wenn der Speicher partitioniert ist. Die Lesevorgänge schlagen daher fehl.
  • In der Demo wird der Erfolg oder Misserfolg jeder Leseoperation verwendet, um anzuzeigen, ob Daten partitioniert sind.

Derzeit können Sie die Speicherpartitionierung in Chrome mithilfe des --disable-features=ThirdPartyStoragePartitioning-Befehlszeilenschalters deaktivieren. Hinweis: Dieser Befehlszeilenschalter ist für Entwicklungs- und Testzwecke gedacht und kann in zukünftigen Chrome-Versionen entfernt oder geändert werden.

Sie können auch andere Browser auf die gleiche Weise testen, um den Partitionsstatus zu sehen.

Mit Nutzern interagieren und Feedback geben