Erweiterungen können Cookies speichern und auf Web Storage APIs zugreifen, ähnlich wie eine normale Website. In einigen Fällen verhalten sie sich in Erweiterungen jedoch anders.
Informationen zur Erweiterungs-API finden Sie unter browser.storage.
Speicher
Es ist oft wünschenswert, Speicher-APIs der Webplattform in Erweiterungen zu verwenden. In diesem Abschnitt wird das Verhalten dieser APIs im Kontext einer Erweiterung beschrieben, das sich manchmal von ihrem Verhalten im Web unterscheidet.
Persistenz
Der Erweiterungsspeicher wird nicht gelöscht, wenn ein Nutzer Browserdaten löscht. Dies gilt für alle Daten, die mit Web Storage-APIs wie Local Storage und IndexedDB gespeichert werden.
Standardmäßig unterliegen Erweiterungen den normalen Kontingentbeschränkungen für den Speicherplatz, die durch Aufrufen von navigator.storage.estimate() geprüft werden können. Speicher kann auch bei starker Speicherauslastung entfernt werden, was jedoch selten vorkommt. So kann dies vermieden werden:
- Fordern Sie die Berechtigung
"unlimitedStorage"an. Diese wirkt sich sowohl auf Erweiterungs- als auch auf Webspeicher-APIs aus und befreit Erweiterungen von Kontingentbeschränkungen und dem Entfernen von Daten. - Rufen Sie
navigator.storage.persist()an, um sich vor einer Zwangsräumung zu schützen.
Der Speicher für Erweiterungen wird für den Ursprung der Erweiterung freigegeben, einschließlich des Service Workers der Erweiterung, aller Erweiterungsseiten (einschließlich Pop-ups und der Seitenleiste) und Offscreen-Dokumente. Wenn in Inhaltsskripten Web Storage APIs aufgerufen werden, wird auf Daten der Hostseite zugegriffen, auf der das Inhaltsskript eingefügt wird, und nicht auf Daten der Erweiterung.
Zugriff in Service Workern
Die APIs IndexedDB und Cache Storage sind in Service Workern verfügbar. Lokaler Speicher und Sitzungsspeicher sind jedoch nicht betroffen.
Wenn Sie vom Service Worker aus auf den lokalen Speicher oder den Sitzungsspeicher zugreifen müssen, verwenden Sie ein Offscreen-Dokument.
Partitionierung
Bei der Partitionierung werden Schlüssel für gespeicherte Daten eingeführt, um den Zugriff darauf zu beschränken. Der Speicher wurde bisher nach Herkunftsschlüssel organisiert.
Ab Chrome 115 werden mit der Speicherpartitionierung Änderungen an der Definition von Partitionierungsschlüsseln eingeführt, um bestimmte Arten von websiteübergreifendem Tracking zu verhindern. In der Praxis bedeutet das: Wenn auf Website A ein iFrame mit Website B eingebettet ist, kann Website B nicht auf denselben Speicher zugreifen, der ihr normalerweise zur Verfügung stünde, wenn sie direkt aufgerufen würde.
Um die Auswirkungen auf Erweiterungen zu verringern, gelten zwei Ausnahmen:
- Wenn eine Seite mit dem Schema
chrome-extension://in eine beliebige Website eingebettet ist, wird die Speicherpartitionierung nicht angewendet und die Erweiterung hat Zugriff auf ihre Partition auf oberster Ebene. - Wenn eine Seite mit dem Schema
chrome-extension://einen iFrame enthält und die Erweiterung Hostberechtigungen für die eingebettete Website hat, hat diese Website auch Zugriff auf ihre Partition auf oberster Ebene.
Kekse
Mit Cookies können Schlüssel/Wert-Paare gespeichert werden, die einer bestimmten Domain und einem bestimmten Pfad zugeordnet sind. Sie sind in Erweiterungen nur von begrenztem Wert. Es kann jedoch nützlich sein, ihr Verhalten zu verstehen, wenn Sie einen bestimmten Anwendungsfall haben oder ein Drittanbieter-Script gebündelt haben, das sie in seiner Implementierung verwendet.
Sichere Cookies
Das Cookie-Attribut Secure wird nur für das https://-Schema unterstützt. Daher können auf chrome-extension://-Seiten keine Cookies mit diesem Attribut gesetzt werden.
Das bedeutet auch, dass auf Erweiterungsseiten keine anderen Cookie-Attribute verwendet werden können, für die das Attribut Secure erforderlich ist:
Partitionierung und SameSite-Verhalten
Für Cookies, die auf chrome-extension://-Seiten festgelegt werden, wird immer SameSite=Lax verwendet.
Folglich kann in Frames nie auf Cookies zugegriffen werden, die von einer Erweiterung in ihrem eigenen Ursprung gesetzt werden, und die Partitionierung ist nicht relevant.
Bei Cookies, die mit Drittanbieterwebsites verknüpft sind, z. B. bei einer Drittanbieterwebsite, die in einem Frame auf einer Erweiterungsseite geladen wird, oder bei einer Anfrage, die von einer Erweiterungsseite an einen Drittanbieterursprung gesendet wird, verhalten sich Cookies genauso wie im Web, mit zwei Ausnahmen:
- Drittanbieter-Cookies werden auch in untergeordneten Frames nie blockiert, wenn die Seite der obersten Ebene für einen bestimmten Tab eine
chrome-extension://-Seite ist. - Anfragen einer Erweiterung an einen Drittanbieter werden als Same-Site-Anfragen behandelt, wenn die Erweiterung Hostberechtigungen für den Drittanbieter hat. Das bedeutet, dass
SameSite=Strict-Cookies gesendet werden können. Das gilt nur für Netzwerkanfragen, nicht für den Zugriff überdocument.cookiein JavaScript. Außerdem gilt es nicht, wenn Drittanbieter-Cookies blockiert werden.
Einstellungen für Drittanbieter-Cookies sind von der Privacy Sandbox betroffen und werden entsprechend dem Zeitplan angepasst.
Die browser.cookies API bietet die Möglichkeit, den Partitionsschlüssel für jede API-Methode festzulegen. Weitere Informationen finden Sie in der API-Referenz.