Storage Access API

Konzepte und Nutzung

Browser implementieren mehrere Zugriffsfunktionen und -richtlinien, die den Zugriff auf Third-Party-Cookies und unpartitionierte Zustände einschränken. Diese reichen von der Bereitstellung eines einzigartigen Cookie-Speichers für eingebettete Ressourcen unter jedem Top-Level-Ursprung (partitionierte Cookies) bis hin zur vollständigen Blockierung des Cookie-Zugriffs, wenn Ressourcen in einem Drittanbieter-Kontext geladen werden.

Die Semantik von Funktionen und Richtlinien zur Blockierung von Third-Party-Cookies und unpartitioniertem Zustand unterscheidet sich von Browser zu Browser, aber die Kernfunktionalität ist ähnlich. Cross-Site-Ressourcen, die in einem Drittanbieter-Kontext eingebettet sind, erhalten keinen Zugriff auf den gleichen Zustand, den sie beim Laden in einem First-Party-Kontext hätten. Dies geschieht in guter Absicht — Browser-Anbieter möchten Maßnahmen ergreifen, um die Privatsphäre und Sicherheit der Nutzer besser zu schützen. Beispiele sind, sie weniger anfällig dafür zu machen, dass ihre Aktivitäten über verschiedene Websites hinweg verfolgt werden, und sie weniger anfällig für Exploits wie Cross-Site-Request-Forgery (CSRF) zu machen.

Es gibt jedoch legitime Nutzungen für eingebettete Cross-Site-Inhalte, die auf Third-Party-Cookies und unpartitionierte Zustände zugreifen, die die oben genannten Funktionen und Richtlinien bekanntermaßen beeinträchtigen. Angenommen, Sie haben eine Reihe verschiedener Websites, die Zugang zu unterschiedlichen Produkten bieten — heads-example.com, shoulders-example.com, knees-example.com und toes-example.com.

Alternativ könnten Sie Ihre Inhalte oder Dienstleistungen in verschiedenen Länderdomains für Lokalisierungszwecke trennen — example.com, example.ua, example.br usw. — oder auf andere Weise.

Sie könnten begleitende Dienstprogramm-Websites mit Komponenten haben, die in allen anderen Websites eingebettet sind, zum Beispiel, um SSO (sso-example.com) oder allgemeine Personalisierungsdienste (services-example.com) bereitzustellen. Diese Dienstprogramm-Websites möchten ihren Zustand über Cookies mit den eingebetteten Websites teilen. Sie können jedoch keine First-Party-Cookies teilen, da sie sich auf unterschiedlichen Domains befinden, und Third-Party-Cookies funktionieren in Browsern, die sie blockieren, nicht mehr.

In solchen Situationen ermutigen Website-Betreiber die Nutzer oft, ihre Website als Ausnahme hinzuzufügen oder die Richtlinien zur Blockierung von Third-Party-Cookies vollständig zu deaktivieren. Nutzer, die weiterhin mit ihren Inhalten interagieren möchten, müssen ihre Blockierungsrichtlinie für Ressourcen, die von allen eingebetteten Ursprüngen geladen werden, und möglicherweise über alle Websites hinweg erheblich lockern.

Die Storage Access API soll dieses Problem lösen; eingebettete Cross-Site-Inhalte können über die Methode Document.requestStorageAccess() unbeschränkten Zugriff auf Third-Party-Cookies und unpartitionierten Zustand Frame-für-Frame anfordern. Sie kann auch überprüfen, ob bereits Zugriff besteht, über die Methode Document.hasStorageAccess().

Unpartitionierte versus partitionierte Cookies

Die Storage Access API wird nur benötigt, um Zugriff auf unpartitionierte Third-Party-Cookies zu gewähren! Unpartitionierte Cookies sind solche, bei denen alle auf derselben Website gesetzten Cookies im selben Cookie-Container gespeichert werden — die traditionelle Methode seit den Anfängen des Webs. Da das Risiko besteht, dass Daten, die für eine Website bestimmt sind, anderen Websites offengelegt werden, blockieren Browser häufig das Senden unpartitionierter Third-Party-Cookies in Anfragen und erlauben den Zugriff auf sie in eingebetteten Kontexten nicht.

Dies steht in Kontrast zu partitionierten Cookies, bei denen eingebettete Ressourcen unter jeder Top-Level-Website einen einzigartigen Cookie-Speicherplatz erhalten, der von denen anderer Sites isoliert ist. Da es kein Privatsphäre-Risiko gibt, da es nicht möglich ist, Nutzer über Websites hinweg durch partitionierte Cookies zu verfolgen, senden Browser partitionierte Cookies in Anfragen und machen sie für eingebettete Ressourcen verfügbar. Beachten Sie jedoch, dass die Cookies nicht zwischen Websites geteilt werden, sie also auch nicht automatisch über Websites synchronisiert werden. Browser haben verschiedene Mechanismen, um den Zugriff auf Third-Party-Cookies zu partitionieren, zum Beispiel Firefox Total Cookie Protection und Cookies Having Independent Partitioned State (CHIPS).

Wenn wir im Zusammenhang mit der Storage Access API über Third-Party-Cookies sprechen, meinen wir implizit unpartitionierte Third-Party-Cookies.

Funktionsweise

Drittanbieter-Inhalte, die in ein <iframe> eingebettet sind, und auf Cookies oder andere unpartitionierte Zustände zugreifen müssen, können den Zugang über die Storage Access API wie folgt anfordern:

1. Document.hasStorageAccess() kann aufgerufen werden, um zu überprüfen, ob der eingebettete Inhalt bereits Zugang zu unpartitionierten Cookies hat.

2. Falls nicht, kann Document.requestStorageAccess() mit transient activation aufgerufen werden, um die storage-access-Berechtigung anzufordern.

   Abhängig vom Browser wird der Nutzer in leicht unterschiedlicher Weise gefragt, ob er die Berechtigung für das anfordernde Embed erteilen möchte.

   • Safari zeigt Aufforderungen für alle eingebetteten Inhalte an, die zuvor keinen Speicherzugriff erhalten haben.
   • Firefox fordert Benutzer nur auf, nachdem eine Herkunft auf mehr als einer Schwelle von Websites Zugang zum Speicher angefordert hat.
   • Chrome zeigt für alle eingebetteten Inhalte Aufforderungen an, die zuvor keinen Speicherzugriff erhalten haben. Es wird jedoch automatisch Zugang gewähren und Aufforderungen überspringen, wenn die eingebetteten Inhalte und die einbettende Seite Teil desselben related website set sind.

3. Die Berechtigung wird erteilt oder verweigert, basierend darauf, ob alle Sicherheitsanforderungen erfüllt sind — siehe Sicherheitshinweise für allgemeine Anforderungen und Browser-spezifische Variationen für einige browser-spezifische Sicherheitsanforderungen. Die auf Promise basierende Natur von requestStorageAccess() ermöglicht es, Code auszuführen, um Erfolgs- und Fehlersituationen zu bearbeiten.

   Sobald die Berechtigung erteilt wird, wird ein Berechtigungsschlüssel im Browser mit der Struktur <top-level site, embedded site> gespeichert. Zum Beispiel, wenn die einbettende Seite embedder.com ist und das Embed locator.example.com ist, wäre der Schlüssel <embedder.com, example.com>.

   Dies bedeutet, dass die Berechtigung für den unpartitionierten Cookie-Zugriff auf jede Seite der Website example.com oder einer ihrer Subdomains gewährt wird, die in jeder Seite der Website embedder.com eingebettet ist. Zum Beispiel können docs.example.com, profile.example.com nun requestStorageAccess() aufrufen und das Versprechen würde automatisch erfüllt.

   Hinweis: Ältere Versionspezifikationen verwendeten die spezifischere Berechtigungsschlüsselstruktur <top-level site, embedded origin>, was bedeutete, dass gleichseitige, cross-origin Embeds nicht mit dem Berechtigungsschlüssel übereinstimmten und den gesamten Prozess separat durchlaufen mussten.

4. Die Berechtigung muss für jeden Kontext explizit aktiviert werden.

   Wenn einem Embed eine Berechtigung gewährt wird, wird diese Berechtigung auch für den aktuellen Kontext aktiviert. Andere Kontexte wie neue Browser-Tabs oder Inhalte in anderen <iframe>-Elementen auf der Seite haben jedoch standardmäßig ihren Third-Party-Cookie-Zugriff blockiert. Das bedeutet, dass auch wenn eine Berechtigung erteilt wurde, die Seite geladen und requestStorageAccess() aufgerufen werden muss, um die Berechtigung zu aktivieren. Wenn die Berechtigung bereits erteilt wurde, ist es nicht erforderlich, eine Transient Activation durchzuführen, und das Versprechen wird automatisch erfüllt.

   Die einzige Ausnahme von dem "standardmäßig blockierten" Verhalten ist, wenn ein Embed nach dem Erteilen oder Aktivieren einer Berechtigung eine gleich-ursprünliche Navigation durchführt, um sich selbst neu zu laden. In solchen Fällen wird der Speicherzugang von der vorherigen Navigation übernommen. Dies ermöglicht es, dass sich die eingebettete Ressource selbst neu lädt und Zugriff auf ihre Cookies erhält.

   Hinweis: In älteren Versionspezifikationen war der Zugriff seitenweise (Safari ist der einzige Browser, der dieses Modell weiterhin verwendet). Wenn ein Embed Third-Party-Cookie-Zugriff über requestStorageAccess() erhielt, erhielten automatisch alle anderen gleichen Site-Embeds Zugriff. Dies war aus sicherheitstechnischer Sicht kein gewünschtes Verhalten — zum Beispiel, wenn shop.example.com locator.users.com embedded, um Nutzern zu ermöglichen, ihre Standortinformationen beim Einkauf zu nutzen, und locator.users.com ruft requestStorageAccess() auf, könnten shop.example.com und alle anderen eingebetteten Seiten auf ihre Cookies zugreifen, aber auch auf Cookies von private.users.com, die nicht eingebettet werden sollen. Lesen Sie mehr über die Motivationen hinter dieser Änderung.

5. Nachdem ein Embed die Speicherzugriffsberechtigung aktiviert hat, sollte es sich selbst neu laden. Der Browser fordert die Ressource erneut mit enthaltenen Third-Party-Cookies an und macht sie der eingebetteten Ressource zugänglich, sobald sie geladen ist. Die Cross-Origin-Anforderungen des Embed folgen der same-origin policy, daher werden Third-Party-Cookies nur mit Anfragen an den genauen Ursprung der eingebetteten Ressource gesendet. Andere Ursprünge innerhalb derselben Site, die auf Third-Party-Cookies zugreifen möchten, müssen die Speicherzugriffsberechtigung separat aktivieren.

Storage Access Headers

Die API erfordert, dass eine Ressource requestStorageAccess() für jeden neuen Kontext aufruft, um die Aktivierung der Speicherzugriffsberechtigung zu wählen, die bereits gewährt sein muss. Dies bedeutet wiederum, dass die eingebettete Ressource zuerst ohne Cookies angefordert und geladen werden muss, damit sie die Methode aufrufen kann.

Die Storage Access Headers ermöglichen einen Arbeitsablauf, bei dem der Server die Aktivierung der Berechtigung für den Kontext anfordern kann, um eine unnötige zusätzliche Ladung der eingebetteten Ressource zu vermeiden, falls die Berechtigung bereits gewährt wurde. Die Ressource muss dennoch geladen werden, um die Berechtigung erstmals anzufordern.

Es gibt zwei Header:

• Der Browser fügt den Sec-Fetch-Storage-Access Header zu Anfragen hinzu, um den Speicherzugriffsstatus des aktuellen Abrufkontexts anzuzeigen, z. B. ob die Berechtigung aktiviert, gewährt oder nicht gewährt wurde.
• Abhängig vom Speicherzugriffsstatus der Anfrage kann der Server mit einem Activate-Storage-Access Header antworten, um den Browser aufzufordern, die Berechtigung für den Kontext zu aktivieren und die Anfrage mit Cookies erneut zu versuchen (um zu vermeiden, dass die Ressource geladen werden muss, damit sie requestStorageAccess() aufrufen kann, um dasselbe zu erreichen), oder die Berechtigung zu aktivieren und die zurückgegebene Ressource zu laden.

Die Storage Access Headers können auch verwendet werden, um Berechtigungen für passive Ressourcen wie Bilder zu aktivieren, vorausgesetzt, der Kontext hat bereits eine Berechtigung erhalten. Dies könnte verwendet werden, um beispielsweise verschiedene Bilder für verschiedene Nutzer, Demografien oder Lokale bereitzustellen.

Die Arbeitsabläufe werden im Abschnitt Speicherzugriffsheader Sequenzen dargestellt.

Request/Response-Fluss

JavaScript-Sequenzen

Betrachten Sie das Beispiel einer Bibliothek, die in einem <iframe> geladen ist, die über eine Anzahl von Websites hinweg geteilt werden muss und sich auf Anmeldedaten in unpartitionierten Cookies verlässt.

Schauen wir zuerst den Fall an, bei dem die Berechtigung nicht erteilt wurde:

1. Der Browser fordert die Ressource an, ohne Third-Party-Cookies einzubeziehen.

2. Der Server antwortet mit einer "Fallback"-Version des Inhalts, die keine Anmeldedaten erfordert und die kein Zugriff auf ihre Cookies hat, wenn sie geladen wird.

   • Sobald sie geladen ist, ruft die Ressource requestStorageAccess() mit transiente Aktivierung auf, um die storage-access-Berechtigung anzufordern und zu aktivieren.
   • Wenn die Berechtigung erteilt wird, lädt sich die Ressource selbst neu.

3. Der Browser fordert die Ressource erneut an, diesmal mit Third-Party-Cookies.

4. Die Serverantwort enthält eine "Anmelde"-Version der Ressource.

Der Browser lädt die Ressource, die Zugriff auf ihre eigenen Cookies hat, da sie eine aktivierte storage-access-Berechtigung hat.

Nun betrachten wir den Fall, bei dem die Berechtigung erteilt, aber nicht aktiviert wurde. Dies würde passieren, wenn Sie dieselbe URL in einem neuen Browser-Tab öffnen oder versuchen, dieselbe Ressource von einer anderen Seite innerhalb derselben Website einzubetten.

Der Arbeitsablauf ist fast genau der gleiche, da die Ressource immer noch zum ersten Mal ohne Cookies geladen werden muss und dann requestStorageAccess() aufrufen muss, um die Berechtigung für den Kontext zu aktivieren. In diesem Fall benötigt es jedoch keine Transient Activation und kann beim Laden ausgeführt werden.

Storage Access Header Sequenzen

Die Storage Access Header ermöglichen einen verbesserten Arbeitsablauf, der es dem Server ermöglicht, den Browser aufzufordern, eine bereits gewährte Berechtigung zu aktivieren und die Anfrage mit enthaltenen Cookies erneut auszuführen. Dies vermeidet die Anforderung, die Ressource für den Aufruf von requestStorageAccess() zu laden, wenn der Nutzer bereits die Berechtigung gewährt hat.

Der Sec-Fetch-Storage-Access Header wird zu Anfragen hinzugefügt, um den Speicherzugriffsstatus des aktuellen Abrufkontexts anzuzeigen, wie z. B. ob die Berechtigung aktiviert, gewährt oder nicht gewährt wurde. Abhängig vom Speicherzugriffsstatus der Anfrage kann der Server mit einem Activate-Storage-Access Header antworten, um den Browser aufzufordern, die Berechtigung für den Kontext zu aktivieren und die Anfrage mit Cookies erneut auszuführen.

Betrachten wir zuerst den Fall des Versuchs, eine eingebettete Ressource für einen neuen Kontext zu laden, dem bereits die Berechtigung gewährt wurde:

1. Der Browser sendet eine Anfrage mit Sec-Fetch-Storage-Access: inactive, um anzugeben, dass die Berechtigung für den Kontext gewährt, aber inaktiv ist.
   • Die Anfrage wird auch den Origin Header enthalten, um dem Server zu helfen zu entscheiden, ob er die Berechtigung aktivieren möchte.
2. Der Server kann mit Activate-Storage-Access: retry antworten, um anzugeben, dass der Browser die Berechtigung aktivieren und die Anfrage mit Cookies erneut versuchen soll.
   • Die Antwort sollte auch den Vary: Sec-Fetch-Storage-Access Header enthalten, da sie vom Wert von Sec-Fetch-Storage-Access abhängt.
   • Beachten Sie, dass der Inhalt nicht in der Antwort enthalten ist.
3. Wenn der Browser die Anfrage wiederholt, fügt er Sec-Fetch-Storage-Access: active zur Anfrage hinzu, zusammen mit den Cookies.
4. Der Server antwortet dann mit Activate-Storage-Access: load, das den Browser anweist, die neue Version der Bibliothek mit Zugriff auf Third-Party-Cookies zu laden.

Der letzte Zustand, den wir berücksichtigen müssen, ist, wenn eine eingebettete Ressource geladen wird, für die keine Berechtigung erteilt wurde:

1. Der Browser sendet eine Anfrage mit Sec-Fetch-Storage-Access: none, um anzugeben, dass die Berechtigung nicht erteilt wurde.

2. Der Server antwortet dann mit der Ressource, die bei Laden die Berechtigung für sicheren Zugriff mit transiente Aktivierung anfordert. Der Activate-Storage-Access Header ist nicht in der Antwort enthalten, aber der Server sollte Vary: Sec-Fetch-Storage-Access hinzufügen.

   Nachdem der Nutzer die Berechtigung erteilt (und damit aktiviert) hat, lädt sich das Embed selbst neu.

3. Der Browser fügt Sec-Fetch-Storage-Access: active zur Anfrage hinzu, um anzugeben, dass der Kontext eine aktivierte storage-access-Berechtigung hat, und schließt die Third-Party-Cookies ein.

4. Der Server antwortet mit Activate-Storage-Access: load, das den Browser anweist, die neue Version der Bibliothek mit Zugriff auf Third-Party-Cookies zu laden.

Sicherheitshinweise

Verschiedene Sicherheitsmaßnahmen könnten dazu führen, dass ein Aufruf von Document.requestStorageAccess() fehlschlägt. Überprüfen Sie die untenstehende Liste, falls Sie Probleme haben, eine Anfrage zum Laufen zu bringen:

1. Die Berechtigungsanfrage muss mit einer Nutzeraktion (transient activation) wie einem Tippen oder Klicken verbunden sein. Dies verhindert, dass eingebettete Inhalte auf der Seite den Browser oder Nutzer mit übermäßigen Anfragen zuspammen. Beachten Sie, dass dies nicht erforderlich ist, wenn:

   • Die Berechtigung zur Nutzung der API wurde bereits einem anderen Kontext mit demselben <top-level site, embedded site> Schlüssel erteilt.
   • Der Anrufer ist ein Top-Level-Dokument oder gleichseitig mit dem Top-Level-Dokument. In solchen Fällen muss requestStorageAccess() wahrscheinlich überhaupt nicht aufgerufen werden.

2. Das Dokument und das Top-Level-Dokument dürfen keinen null-Urspung haben.

3. Ursprünge, mit denen als First-Party nie interagiert wurde, haben keinen Begriff von First-Party-Speicher. Aus der Perspektive des Nutzers haben sie nur eine Drittanbieterbeziehung mit diesem Ursprung. Zugriffsanfragen werden automatisch abgelehnt, wenn der Browser erkennt, dass der Nutzer kürzlich (in Firefox innerhalb von 30 Tagen) nicht mit dem eingebetteten Inhalt in einem First-Party-Kontext interagiert hat.

4. Das Fenster des Dokuments muss ein sicherer Kontext sein.

5. Sandboxed <iframe>s können aus Sicherheitsgründen standardmäßig keinen Speicherzugriff erhalten. Um dies zu handhaben, bietet die API das allow-storage-access-by-user-activation sandbox token. Das <iframe> muss dies einschließen, um Speicherzugriffsanfragen zu ermöglichen, zusammen mit allow-scripts und allow-same-origin, um das Ausführen eines Skripts zu ermöglichen, das die API aufrufen und in einem Ursprung ausführen kann, der Cookies/Zustand haben darf:

   html

   <iframe
     sandbox="allow-storage-access-by-user-activation
                   allow-scripts
                   allow-same-origin">
     …
   </iframe>
   

6. Die Verwendung dieses Features kann durch eine storage-access Berechtigungsrichtlinie blockiert werden, die auf Ihrem Server festgelegt ist.

Browser-spezifische Variationen

Obwohl die API-Oberfläche gleich ist, sollten Websites, die die Storage Access API verwenden, Unterschiede in der Ebene und dem Umfang des Zugriffs auf Third-Party-Cookies erwarten, den sie zwischen verschiedenen Browsern erhalten, aufgrund von Unterschieden in deren Zugriffspolitiken.

Chrome

• Cookies müssen explizit SameSite=None gesetzt haben, da der Standardwert für Chrome SameSite=Lax ist (SameSite=None ist der Standard in Firefox und Safari).
• Cookies müssen das Secure Attribut gesetzt haben.
• Die Speicherzugriffsgewährungen laufen nach 30 Tagen Browsernutzung ohne Benutzereingriff aus. Interaktion mit dem eingebetteten Inhalt verlängert diese Grenze um weitere 30 Tage. Dies geschieht nicht, wenn Document.requestStorageAccessFor() aufgerufen wird, da der Nutzer bereits auf der Seite ist.

Firefox

• Wenn der eingebettete Ursprung tracker.example bereits Zugriff auf Third-Party-Cookies auf dem Top-Level-Ursprung foo.example erhalten hat und der Nutzer eine Seite von foo.example besucht, die eine Seite von tracker.example erneut innerhalb von weniger als 30 Tagen einbettet, hat der eingebettete Ursprung sofortigen Zugriff auf Third-Party-Cookies beim Laden.
• Die Speicherzugriffsgewährungen laufen nach 30 Kalendertagen aus.

Die Dokumentation zur neuen Speicherzugriffspolitik von Firefox für die Blockierung von Tracking-Cookies enthält eine detaillierte Beschreibung des Umfangs von Speicherzugriffsgewährungen.

Safari

• Die Speicherzugriffsgewährungen verlaufen nach 30 Tagen Browsernutzung ohne Benutzereingriff. Eine erfolgreiche Nutzung der Storage Access API setzt diesen Zähler zurück.
• Nachdem ein Embed die Speicherzugriffsberechtigung aktiviert hat und sein Inhalt erneut angefordert wurde, werden Third-Party-Cookies mit Anfragen an die Seite der eingebetteten Ressource gesendet und nicht an den Ursprung. Safari verwendet immer noch ein älteres Design, das nicht der same-origin policy folgt.

Beispiele

• Siehe Die Storage Access API verwenden für einen Implementierungsleitfaden mit Codebeispielen.

API Methoden

Document.hasStorageAccess()

Gibt ein Promise zurück, das sich mit einem boolean Wert auflöst, der angibt, ob das Dokument Zugriff auf Third-Party-Cookies hat.

Document.hasUnpartitionedCookieAccess()

Neuer Name für Document.hasStorageAccess().

Document.requestStorageAccess()

Ermöglicht Inhalten, die in einem Third-Party-Kontext geladen werden (d.h. eingebettet in ein <iframe>), Zugriff auf Third-Party-Cookies und unpartitionierten Zustand zu beantragen; gibt ein Promise zurück, das sich erfüllt, wenn der Zugriff gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.

Document.requestStorageAccessFor()

Eine nicht standardisierte veraltete Erweiterung der Storage Access API, die es Top-Level-Sites ermöglicht, Third-Party-Cookie-Zugriff im Namen von eingebetteten Inhalten von einer anderen Site innerhalb desselben related website set zu beantragen. Gibt ein Promise zurück, das sich erfüllt, wenn der Zugriff gewährt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.

Ergänzungen zu anderen APIs

Permissions.query(), der "storage-access" Feature-Name

In unterstützenden Browsern kann dieser abgefragt werden, ob Zugriff auf Third-Party-Cookies allgemein gewährt wurde, also für ein anderes gleichseitiges Embed. Falls ja, kann requestStorageAccess() ohne Benutzerinteraktion aufgerufen werden, und das Promise wird automatisch aufgelöst.

Permissions.query(), der "top-level-storage-access" Feature-Name

Ein separater Feature-Name wird verwendet, um abzufragen, ob die Berechtigung zum Zugriff auf Third-Party-Cookies bereits über requestStorageAccessFor() gewährt wurde. Falls ja, müssen Sie requestStorageAccessFor() nicht erneut aufrufen.

Ergänzungen zu HTTP

Permissions-Policy

Permissions-Policy: storage-access

Die storage-access Permissions-Policy Direktive steuert, ob ein Dokument, das in einem Third-Party-Kontext geladen wird (d.h. eingebettet in ein <iframe>), die Storage Access API verwenden darf, um Zugriff auf unpartitionierte Cookies zu beantragen.

Storage Access Headers

Sec-Fetch-Storage-Access

Gibt den "Storage Access Status" für den aktuellen Anforderungskontext an, der einer von: none, inactive oder active sein wird.

Activate-Storage-Access

Wird als Antwort auf Sec-Fetch-Storage-Access verwendet, um anzugeben, dass der Browser eine bestehende Berechtigung für sicheren Zugriff aktivieren und die Anfrage mit Cookies erneut ausführen oder eine Ressource mit Cookie-Zugriff laden kann, wenn er bereits eine aktivierte Berechtigung hat.

Spezifikationen

Browser-Kompatibilität

api.Document.hasStorageAccess

api.Document.hasUnpartitionedCookieAccess

api.Document.requestStorageAccess

api.Document.requestStorageAccessFor

api.Permissions.permission_storage-access

http.headers.Activate-Storage-Access

http.headers.Sec-Fetch-Storage-Access

Siehe auch

• Die Storage Access API verwenden
• Einführung der Storage Access API (WebKit-Blog)