Storage Access API

Konzepte und Nutzung

Browser implementieren mehrere Zugriffsfunktionen und -richtlinien, die den Zugriff auf Third-Party-Cookies und unpartitionierte Zustnde einschrnken. Diese reichen von der Bereitstellung eines einzigartigen Cookie-Speichers fr eingebettete Ressourcen unter jedem Top-Level-Ursprung (partitionierte Cookies) bis hin zur vollstndigen 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 Kernfunktionalitt 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 htten. Dies geschieht in guter Absicht Browser-Anbieter mchten Manahmen ergreifen, um die Privatsphre und Sicherheit der Nutzer besser zu schtzen. Beispiele sind, sie weniger anfllig dafr zu machen, dass ihre Aktivitten ber verschiedene Websites hinweg verfolgt werden, und sie weniger anfllig fr Exploits wie Cross-Site-Request-Forgery (CSRF) zu machen.

Es gibt jedoch legitime Nutzungen fr eingebettete Cross-Site-Inhalte, die auf Third-Party-Cookies und unpartitionierte Zustnde zugreifen, die die oben genannten Funktionen und Richtlinien bekanntermaen beeintrchtigen. 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 knnten Sie Ihre Inhalte oder Dienstleistungen in verschiedenen Lnderdomains fr Lokalisierungszwecke trennen example.com, example.ua, example.br usw. oder auf andere Weise.

Sie knnten 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 mchten ihren Zustand ber Cookies mit den eingebetteten Websites teilen. Sie knnen 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 hinzuzufgen oder die Richtlinien zur Blockierung von Third-Party-Cookies vollstndig zu deaktivieren. Nutzer, die weiterhin mit ihren Inhalten interagieren mchten, mssen ihre Blockierungsrichtlinie fr Ressourcen, die von allen eingebetteten Ursprngen geladen werden, und mglicherweise ber alle Websites hinweg erheblich lockern.

Die Storage Access API soll dieses Problem lsen; eingebettete Cross-Site-Inhalte knnen ber die Methode Document.requestStorageAccess() unbeschrnkten Zugriff auf Third-Party-Cookies und unpartitionierten Zustand Frame-fr-Frame anfordern. Sie kann auch berprfen, ob bereits Zugriff besteht, ber die Methode Document.hasStorageAccess().

Unpartitionierte versus partitionierte Cookies

Die Storage Access API wird nur bentigt, um Zugriff auf unpartitionierte Third-Party-Cookies zu gewhren! Unpartitionierte Cookies sind solche, bei denen alle auf derselben Website gesetzten Cookies im selben Cookie-Container gespeichert werden die traditionelle Methode seit den Anfngen des Webs. Da das Risiko besteht, dass Daten, die fr eine Website bestimmt sind, anderen Websites offengelegt werden, blockieren Browser hufig 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 Privatsphre-Risiko gibt, da es nicht mglich ist, Nutzer ber Websites hinweg durch partitionierte Cookies zu verfolgen, senden Browser partitionierte Cookies in Anfragen und machen sie fr eingebettete Ressourcen verfgbar. 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 Zustnde zugreifen mssen, knnen den Zugang ber die Storage Access API wie folgt anfordern:

1. Document.hasStorageAccess() kann aufgerufen werden, um zu berprfen, 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.

   Abhngig vom Browser wird der Nutzer in leicht unterschiedlicher Weise gefragt, ob er die Berechtigung fr das anfordernde Embed erteilen mchte.

   • Safari zeigt Aufforderungen fr 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 fr alle eingebetteten Inhalte Aufforderungen an, die zuvor keinen Speicherzugriff erhalten haben. Es wird jedoch automatisch Zugang gewhren 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 erfllt sind siehe Sicherheitshinweise fr allgemeine Anforderungen und Browser-spezifische Variationen fr einige browser-spezifische Sicherheitsanforderungen. Die auf Promise basierende Natur von requestStorageAccess() ermglicht es, Code auszufhren, um Erfolgs- und Fehlersituationen zu bearbeiten.

   Sobald die Berechtigung erteilt wird, wird ein Berechtigungsschlssel 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, wre der Schlssel <embedder.com, example.com>.

   Dies bedeutet, dass die Berechtigung fr den unpartitionierten Cookie-Zugriff auf jede Seite der Website example.com oder einer ihrer Subdomains gewhrt wird, die in jeder Seite der Website embedder.com eingebettet ist. Zum Beispiel knnen docs.example.com, profile.example.com nun requestStorageAccess() aufrufen und das Versprechen wrde automatisch erfllt.

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

4. Die Berechtigung muss fr jeden Kontext explizit aktiviert werden.

   Wenn einem Embed eine Berechtigung gewhrt wird, wird diese Berechtigung auch fr den aktuellen Kontext aktiviert. Andere Kontexte wie neue Browser-Tabs oder Inhalte in anderen <iframe>-Elementen auf der Seite haben jedoch standardmig 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 durchzufhren, und das Versprechen wird automatisch erfllt.

   Die einzige Ausnahme von dem "standardmig blockierten" Verhalten ist, wenn ein Embed nach dem Erteilen oder Aktivieren einer Berechtigung eine gleich-ursprnliche Navigation durchfhrt, um sich selbst neu zu laden. In solchen Fllen wird der Speicherzugang von der vorherigen Navigation bernommen. Dies ermglicht es, dass sich die eingebettete Ressource selbst neu ldt und Zugriff auf ihre Cookies erhlt.

   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 gewnschtes Verhalten zum Beispiel, wenn shop.example.com locator.users.com embedded, um Nutzern zu ermglichen, ihre Standortinformationen beim Einkauf zu nutzen, und locator.users.com ruft requestStorageAccess() auf, knnten 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 zugnglich, 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 Ursprnge innerhalb derselben Site, die auf Third-Party-Cookies zugreifen mchten, mssen die Speicherzugriffsberechtigung separat aktivieren.

Storage Access Headers

Die API erfordert, dass eine Ressource requestStorageAccess() fr jeden neuen Kontext aufruft, um die Aktivierung der Speicherzugriffsberechtigung zu whlen, die bereits gewhrt 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 ermglichen einen Arbeitsablauf, bei dem der Server die Aktivierung der Berechtigung fr den Kontext anfordern kann, um eine unntige zustzliche Ladung der eingebetteten Ressource zu vermeiden, falls die Berechtigung bereits gewhrt wurde. Die Ressource muss dennoch geladen werden, um die Berechtigung erstmals anzufordern.

Es gibt zwei Header:

• Der Browser fgt den Sec-Fetch-Storage-Access Header zu Anfragen hinzu, um den Speicherzugriffsstatus des aktuellen Abrufkontexts anzuzeigen, z. B. ob die Berechtigung aktiviert, gewhrt oder nicht gewhrt wurde.
• Abhngig vom Speicherzugriffsstatus der Anfrage kann der Server mit einem Activate-Storage-Access Header antworten, um den Browser aufzufordern, die Berechtigung fr 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 zurckgegebene Ressource zu laden.

Die Storage Access Headers knnen auch verwendet werden, um Berechtigungen fr passive Ressourcen wie Bilder zu aktivieren, vorausgesetzt, der Kontext hat bereits eine Berechtigung erhalten. Dies knnte verwendet werden, um beispielsweise verschiedene Bilder fr verschiedene Nutzer, Demografien oder Lokale bereitzustellen.

Die Arbeitsablufe 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 verlsst.

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, ldt sich die Ressource selbst neu.

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

4. Die Serverantwort enthlt eine "Anmelde"-Version der Ressource.

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

[Storage API Workflow - ohne storage-access Berechtigung]

Nun betrachten wir den Fall, bei dem die Berechtigung erteilt, aber nicht aktiviert wurde. Dies wrde 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 fr den Kontext zu aktivieren. In diesem Fall bentigt es jedoch keine Transient Activation und kann beim Laden ausgefhrt werden.

[Storage API Workflow - Activating storage-access permission]

Storage Access Header Sequenzen

Die Storage Access Header ermglichen einen verbesserten Arbeitsablauf, der es dem Server ermglicht, den Browser aufzufordern, eine bereits gewhrte Berechtigung zu aktivieren und die Anfrage mit enthaltenen Cookies erneut auszufhren. Dies vermeidet die Anforderung, die Ressource fr den Aufruf von requestStorageAccess() zu laden, wenn der Nutzer bereits die Berechtigung gewhrt hat.

Der Sec-Fetch-Storage-Access Header wird zu Anfragen hinzugefgt, um den Speicherzugriffsstatus des aktuellen Abrufkontexts anzuzeigen, wie z. B. ob die Berechtigung aktiviert, gewhrt oder nicht gewhrt wurde. Abhngig vom Speicherzugriffsstatus der Anfrage kann der Server mit einem Activate-Storage-Access Header antworten, um den Browser aufzufordern, die Berechtigung fr den Kontext zu aktivieren und die Anfrage mit Cookies erneut auszufhren.

Betrachten wir zuerst den Fall des Versuchs, eine eingebettete Ressource fr einen neuen Kontext zu laden, dem bereits die Berechtigung gewhrt wurde:

1. Der Browser sendet eine Anfrage mit Sec-Fetch-Storage-Access: inactive, um anzugeben, dass die Berechtigung fr den Kontext gewhrt, aber inaktiv ist.
   • Die Anfrage wird auch den Origin Header enthalten, um dem Server zu helfen zu entscheiden, ob er die Berechtigung aktivieren mchte.
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 abhngt.
   • Beachten Sie, dass der Inhalt nicht in der Antwort enthalten ist.
3. Wenn der Browser die Anfrage wiederholt, fgt 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.

[Storage Access Header Workflow - Aktivierung der storage-access Berechtigung und Wiederholung]

Der letzte Zustand, den wir bercksichtigen mssen, ist, wenn eine eingebettete Ressource geladen wird, fr 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 fr 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 hinzufgen.

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

3. Der Browser fgt Sec-Fetch-Storage-Access: active zur Anfrage hinzu, um anzugeben, dass der Kontext eine aktivierte storage-access-Berechtigung hat, und schliet 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.

[Storage Access Header Workflow - ohne storage-access Berechtigung]

Sicherheitshinweise

Verschiedene Sicherheitsmanahmen knnten dazu fhren, dass ein Aufruf von Document.requestStorageAccess() fehlschlgt. berprfen 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 bermigen 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> Schlssel erteilt.
   • Der Anrufer ist ein Top-Level-Dokument oder gleichseitig mit dem Top-Level-Dokument. In solchen Fllen muss requestStorageAccess() wahrscheinlich berhaupt nicht aufgerufen werden.

2. Das Dokument und das Top-Level-Dokument drfen keinen null-Urspung haben.

3. Ursprnge, 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 krzlich (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 knnen aus Sicherheitsgrnden standardmig keinen Speicherzugriff erhalten. Um dies zu handhaben, bietet die API das allow-storage-access-by-user-activation sandbox token. Das <iframe> muss dies einschlieen, um Speicherzugriffsanfragen zu ermglichen, zusammen mit allow-scripts und allow-same-origin, um das Ausfhren eines Skripts zu ermglichen, das die API aufrufen und in einem Ursprung ausfhren 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-Oberflche 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 mssen explizit SameSite=None gesetzt haben, da der Standardwert fr Chrome SameSite=Lax ist (SameSite=None ist der Standard in Firefox und Safari).
• Cookies mssen das Secure Attribut gesetzt haben.
• Die Speicherzugriffsgewhrungen laufen nach 30 Tagen Browsernutzung ohne Benutzereingriff aus. Interaktion mit dem eingebetteten Inhalt verlngert 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 Speicherzugriffsgewhrungen laufen nach 30 Kalendertagen aus.

Die Dokumentation zur neuen Speicherzugriffspolitik von Firefox fr die Blockierung von Tracking-Cookies enthlt eine detaillierte Beschreibung des Umfangs von Speicherzugriffsgewhrungen.

Safari

• Die Speicherzugriffsgewhrungen verlaufen nach 30 Tagen Browsernutzung ohne Benutzereingriff. Eine erfolgreiche Nutzung der Storage Access API setzt diesen Zhler zurck.
• 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 fr einen Implementierungsleitfaden mit Codebeispielen.

API Methoden

Document.hasStorageAccess()

Gibt ein Promise zurck, das sich mit einem boolean Wert auflst, der angibt, ob das Dokument Zugriff auf Third-Party-Cookies hat.

Document.hasUnpartitionedCookieAccess()

Neuer Name fr Document.hasStorageAccess().

Document.requestStorageAccess()

Ermglicht 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 zurck, das sich erfllt, wenn der Zugriff gewhrt 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 ermglicht, Third-Party-Cookie-Zugriff im Namen von eingebetteten Inhalten von einer anderen Site innerhalb desselben related website set zu beantragen. Gibt ein Promise zurck, das sich erfllt, wenn der Zugriff gewhrt wurde, und abgelehnt wird, wenn der Zugriff verweigert wurde.

Ergnzungen zu anderen APIs

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

In untersttzenden Browsern kann dieser abgefragt werden, ob Zugriff auf Third-Party-Cookies allgemein gewhrt wurde, also fr ein anderes gleichseitiges Embed. Falls ja, kann requestStorageAccess() ohne Benutzerinteraktion aufgerufen werden, und das Promise wird automatisch aufgelst.

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() gewhrt wurde. Falls ja, mssen Sie requestStorageAccessFor() nicht erneut aufrufen.

Ergnzungen 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" fr 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 fr sicheren Zugriff aktivieren und die Anfrage mit Cookies erneut ausfhren oder eine Ressource mit Cookie-Zugriff laden kann, wenn er bereits eine aktivierte Berechtigung hat.

Spezifikationen

Spezifikation
The Storage Access API
Extending Storage Access API (SAA) to non-cookie storage

Browser-Kompatibilitt

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
• Einfhrung der Storage Access API (WebKit-Blog)