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 der Erweiterung 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 die das Inhaltsskript eingefügt wird, und nicht auf die 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 Local Storage oder Session Storage 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 einzuschrä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, dass Website B nicht auf denselben Speicher zugreifen kann, den sie normalerweise hätte, wenn sie direkt aufgerufen wird, wenn Website A einen iFrame mit Website B einbettet.
Um die Auswirkungen auf Erweiterungen zu verringern, gelten zwei Ausnahmen:
- Wenn eine Seite mit dem
chrome-extension://-Schema in eine 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 lassen sich Schlüssel/Wert-Paare speichern, 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 Drittanbieterskript 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 Seiten vom Typ „chrome-extension://“ 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. für eine Drittanbieterwebsite, die in einem Frame auf einer Erweiterungsseite geladen wird, oder für eine Anfrage, die von einer Erweiterungsseite an eine Drittanbieterquelle 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 von 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. Dies gilt nur für Netzwerkanfragen, nicht für den Zugriff überdocument.cookiein JavaScript. Außerdem gilt es nicht, wenn Drittanbieter-Cookies blockiert sind.
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.