Speicherpartitionierung

Um den Datenschutz der Nutzer zu verbessern und websiteübergreifendes Tracking bei Seitenkanälen zu verhindern, isoliert Chrome die meisten Speicher- und Kommunikations-APIs in Drittanbieterkontexten durch einen Prozess namens Speicherpartitionierung.

Implementierungsstatus

Die Funktion wurde für alle Nutzer in Chrome 115 und höher aktiviert. Ähnliche Bemühungen zur Speicherpartitionierung sind auch in anderen wichtigen Browsern wie Firefox und Safari im Gange oder geplant. Der Vorschlag zur Speicherpartitionierung auf GitHub ist offen für weitere Diskussionen.

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 den Nutzer im Web zu verfolgen. Außerdem kann die eingebettete Website mithilfe von Side-Channel-Techniken wie Timing Attacks, XS-Leaks und COSI bestimmte Status des Nutzers auf der Website der obersten Ebene ableiten.

Bisher wurde der Speicher nur nach Herkunftsschlüssel indexiert. Wenn also ein iFrame von example.com auf a.com und b.com eingebettet ist, kann example.com Ihre Browsing-Gewohnheiten für diese beiden Websites ermitteln, indem eine ID im Speicher abgelegt und abgerufen wird. Wenn die Drittanbieter-Speicherpartitionierung aktiviert ist, ist der Speicher für example.com in zwei verschiedenen Partitionen vorhanden: eine für a.com und die andere für b.com.

Im Allgemeinen bedeutet Partitionierung, dass Daten, die von Speicher-APIs wie Local Storage und IndexedDB in einem iFrame geschrieben werden, nicht mehr von allen Kontexten mit demselben Ursprung aufgerufen werden können. Stattdessen sind diese Daten jetzt isoliert und nur für Kontexte verfügbar, die sowohl denselben Ursprung als auch dieselbe Website der obersten Ebene haben.

Vorher

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

Nach

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 bei verketteten iFrames

Die Komplexität der Speicherpartitionierung steigt erheblich, wenn iFrames verschachtelt sind, insbesondere wenn derselbe Ursprung 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 „Erstanbieter“ behandelt, da es eine Website mit der obersten Ebene (A1) gemeinsam nutzt, obwohl sich dazwischen der websiteübergreifende iFrame B befindet. Dadurch könnte A2 Sicherheitsrisiken wie Clickjacking ausgesetzt sein, wenn A2 standardmäßig Zugriff auf nicht partitionierten Speicher hätte.

Um dieses Problem zu beheben, fügt Chrome dem Speicherschlüssel der Partition ein Ancestor-Bit hinzu. Dieses Bit wird gesetzt, wenn ein Dokument zwischen dem aktuellen iFrame und der Website der obersten Ebene von einer anderen (websiteübergreifenden) Herkunft stammt. In diesem Fall ist Website B websiteübergreifend. Das Bit wird also für A2 festgelegt und der Speicher wird von A1 partitioniert.

Wenn die Iframe-Kette nur aus Kontexten derselben Website besteht (z. B. Website A1 mit A2, die dann A3 enthält), wird der Speicher durch das Ancestor-Bit nicht weiter partitioniert. In solchen Fällen bleibt der Speicher gemeinsam, wobei der gemeinsame Ursprung und die Website der obersten Ebene als Schlüssel dienen.

Für Websites, die nicht partitionierten Zugriff über verkettete iFrames benötigen, wird in Chrome die Storage Access API erweitert, um diesen Anwendungsfall zu ermöglichen. Da für die Storage Access API erforderlich ist, dass die Website im Frame die API explizit aufruft, wird das Risiko von Clickjacking 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. Im Kontingentsystem wird jede Partition als separater Bucket verwaltet, um zu ermitteln, wie viel Speicherplatz zulässig ist und wann er geleert wird.
    Die Methode navigator.storage.estimate() enthält jetzt Informationen speziell zur Speicherpartition. Chrome-only 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 über Kontingente verwaltet, sind aber trotzdem 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 den Zugriff gewährt hat. Mit dem Origin Private File System kann ein Ursprung private Inhalte direkt auf der Festplatte speichern. Diese Inhalte bleiben für Nutzer zugänglich, sind aber jetzt partitioniert.
  • Storage Bucket API
    Die Storage Bucket API wird für Storage Standard entwickelt, das verschiedene Speicher-APIs wie IndexedDB und localStorage durch die Verwendung eines neuen Konzepts namens „Buckets“ konsolidiert. Die in den Buckets gespeicherten Daten und die mit den Buckets verknüpften Metadaten werden partitioniert.
  • Clear-Site-Data-Header
    Wenn der Clear-Site-Data-Header in die Antwort aufgenommen wird, kann ein Server anfordern, dass die im Browser des Nutzers gespeicherten Daten gelöscht werden. Cache, Cookies und DOM-Speicher können gelöscht werden. Wenn Sie nur den Header verwenden, wird der Speicherplatz nur in einer Partition gelöscht.
  • Blob-URL speichern
    Eine Blob-URL bietet Zugriff auf ein blob, ein Objekt, das Rohdaten enthält. Ohne Speicherpartitionierung kann eine Blob-URL, die in einem Drittanbieter-iFrame auf einer Website generiert wurde, in einem iFrame mit demselben Ursprung verwendet werden, das in eine andere Website eingebettet ist. Wenn beispielsweise example.com-iFrames sowohl auf a.com als auch auf b.com eingebettet sind, kann eine Blob-URL, die im iFrame auf a.com generiert wird, ohne Einschränkungen an das iFrame auf b.com übergeben und von diesem verwendet werden. Ab Chrome 137 (veröffentlicht am 27. Mai 2025) werden Blob-URLs für alle Verwendungszwecke außer Navigationen der obersten Ebene partitioniert. Fälle, die jetzt blockiert werden, sind unter anderem, wenn Blob-URLs für mehrere Partitionen mit fetch() oder als src-Attributwert für verschiedene HTML-Elemente verwendet werden. Navigationen der obersten Ebene, z. B. durch Aufrufen von window.open() oder Klicken auf einen Link mit target='_blank', zu Blob-URLs werden nicht blockiert, wenn sie partitionierungsübergreifend sind. noopener wird jedoch erzwungen, wenn die Blob-URL-Website websiteübergreifend von der Website der obersten Ebene der Seite ist, die die Navigation initiiert. Wenn noopener erzwungen wird, kann das Dokument, das die Navigation initiiert, kein Fensterhandle für das Blob-URL-Dokument abrufen, das es geöffnet hat. Im vorherigen Beispiel wird durch die Partitionierung verhindert, dass das iFrame auf b.com den Inhalt der Blob-URL abruft. Es kann jedoch weiterhin window.open().

Kommunikations-APIs

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

Aufgrund der Partitionierung verhindern die folgenden Kommunikations-APIs, dass Drittanbieter-IFrames Daten mit ihren Kontexten mit demselben Ursprung austauschen:

  • Broadcast-Channel
    Die Broadcast Channel API ermöglicht die Kommunikation zwischen Browsing-Kontexten (Fenstern, 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 desselben Ursprungs zugegriffen werden kann.
  • Web Locks
    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 Aufgabe ausgeführt wird.

Service Worker API

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

Aus diesem Grund werden Service Worker, die in einem Drittanbieterkontext registriert sind, jetzt partitioniert.

Erweiterungs-APIs

Erweiterungen sind Programme, mit denen Nutzer ihren Browser anpassen können.

Erweiterungsseiten (Seiten mit dem Schema chrome-extension://) können auf Websites im gesamten 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 auf oberster Ebene zu, sofern die Erweiterung Hostberechtigungen für sie hat.

Weitere Informationen finden Sie in der Dokumentation zu Erweiterungen.

Demo: Speicherpartitionierung testen

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

Demowebsite mit grünen Häkchen auf der linken und roten Kreuzen auf der rechten Seite.
Screenshot der Demo mit der Ausgabe für einen Browser mit Speicherpartitionierung auf der linken Seite und ohne Speicherpartitionierung auf der rechten Seite.

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

  • Wenn Sie Website A im Kontext der obersten Ebene aufrufen, werden Daten mit verschiedenen Speichermethoden festgelegt.
  • Auf Website B wird eine Seite von Website A eingebettet und bei diesem Einbetten wird versucht, die zuvor festgelegten Speicheroptionen zu lesen.
  • Wenn Website A auf Website B eingebettet ist, hat sie keinen Zugriff auf diese Daten, wenn der Speicher partitioniert ist. Daher schlagen die Lesevorgänge fehl.
  • In der Demo wird anhand des Erfolgs oder Misserfolgs jedes Lesevorgangs gezeigt, ob Daten partitioniert sind.

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

Sie können auch andere Browser auf diese Weise testen, um ihren Partitionierungsstatus zu sehen.

Zusätzliche Migrationszeit anfordern

Für Websites, die zusätzliche Zeit für die Migration ihrer Abhängigkeiten benötigen, wird der Test zur Einstellung von DisableThirdPartyStoragePartitioning3 verlängert. Dieser Testlauf bietet einen temporären Mechanismus für Websites der obersten Ebene, um nicht partitionierten Speicher, Service Worker und Kommunikations-APIs für Drittanbieterkontexte zu aktivieren, die auf ihren Seiten eingebettet sind.

Weitere Informationen finden Sie unter Verlängerung des Testzeitraums für die Einstellung der Speicherpartitionierung.

Feedback geben