Storage Access API

Konzepte und Verwendung

Browser implementieren mehrere Speicherzugriffsfunktionen und -richtlinien, die den Zugriff auf Drittanbieter-Cookies und unpartitionierten Status einschränken. Diese reichen von der Bereitstellung eines einzigartigen Speicherbereichs für Cookies (partitionierte Cookies) für eingebettete Ressourcen unter jedem obersten Ursprung bis hin zum vollständigen Blockieren des Cookie-Zugriffs, wenn Ressourcen in einem Drittanbieter-Kontext geladen werden.

Die Semantik der Funktionen und Richtlinien zur Blockierung von Drittanbieter-Cookies und unpartitioniertem Status unterscheidet sich von Browser zu Browser, aber die Kernfunktionalität ist ähnlich. Im Drittanbieter-Kontext eingebettete domänenübergreifende Ressourcen erhalten keinen Zugriff auf den gleichen Status, auf den sie im Erstanbieter-Kontext zugreifen könnten. Dies geschieht mit guter Absicht — Browserhersteller möchten Schritte unternehmen, um die Privatsphäre und Sicherheit ihrer Nutzer besser zu schützen. Beispiele hierfür sind, sie weniger anfällig für das Verfolgen ihrer Aktivitäten über verschiedene Websites hinweg zu machen, und sie weniger anfällig für Exploits wie Cross-Site Request Forgery (CSRF) zu machen.

Es gibt jedoch legitime Verwendungen für eingebettete domänenübergreifende Inhalte, die auf Drittanbieter-Cookies und unpartitionierten Status zugreifen, die durch die oben genannten Funktionen und Richtlinien beeinträchtigt werden. Nehmen wir an, Sie betreiben eine Reihe unterschiedlicher Websites, die Zugriff auf verschiedene Produkte bieten — heads-example.com, shoulders-example.com, knees-example.com und toes-example.com.

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

Vielleicht haben Sie begleitende Utility-Websites mit Komponenten, die in alle anderen Websites eingebettet sind, beispielsweise um SSO (sso-example.com) oder generalisierte Personalisierungsdienste (services-example.com) bereitzustellen. Diese Utility-Websites möchten ihren Status mithilfe von Cookies mit den Websites teilen, in denen sie eingebettet sind. Sie können keine Erstanbieter-Cookies teilen, weil sie auf unterschiedlichen Domains liegen, und Drittanbieter-Cookies funktionieren in Browsern, die sie blockieren, nicht mehr.

In solchen Situationen ermutigen Website-Betreiber oft die Benutzer, ihre Website als Ausnahme hinzuzufügen oder Drittanbieter-Cookie-Blockierungsrichtlinien vollständig zu deaktivieren. Benutzer, die weiterhin mit ihrem Inhalt interagieren möchten, müssen ihre Blockierungsrichtlinie für Ressourcen aus allen eingebetteten Ursprüngen und möglicherweise über alle Websites hinweg erheblich lockern.

Die Storage Access API ist vorgesehen, um dieses Problem zu lösen; eingebettete domänenübergreifende Inhalte können über die Methode Document.requestStorageAccess() uneingeschränkten Zugriff auf Drittanbieter-Cookies und unpartitionierten Status frameweise anfordern. Sie kann auch mittels der Methode Document.hasStorageAccess() überprüfen, ob sie bereits Zugriff hat.

Unpartitionierte versus partitionierte Cookies

Die Storage Access API wird nur benötigt, um Zugriff auf unpartitionierte Drittanbieter-Cookies zu gewähren! Unpartitionierte Cookies sind solche, bei denen alle auf derselben Seite gesetzten Cookies im selben Cookie-Container gespeichert sind — die traditionelle Methode seit den Anfängen des Webs. Da die Gefahr besteht, Daten, die für eine Website bestimmt sind, für andere freizulegen, blockieren Browser häufig das Senden von unpartitionierten Drittanbieter-Cookies in Anfragen und erlauben keinen Zugriff auf sie in eingebetteten Kontexte.

Dies steht im Gegensatz zu partitionierten Cookies, bei denen eingebetteten Ressourcen unter jeder obersten Website ein einzigartiger Cookie-Speicherplatz zugewiesen wird, der von denen anderer Websites isoliert ist. Da kein Risiko für die Privatsphäre besteht, weil es nicht möglich ist, Benutzer über Websites hinweg über partitionierte Cookies zu verfolgen, senden Browser partitionierte Cookies in Anfragen und machen sie eingebetteten Ressourcen verfügbar. Beachten Sie jedoch, dass, da die Cookies nicht zwischen den Websites geteilt werden, sie auch nicht automatisch über Websites hinweg synchronisiert werden. Browser haben verschiedene Mechanismen, um den Zugriff auf Drittanbieter-Cookies zu partitionieren, beispielsweise Firefox Total Cookie Protection und Cookies Having Independent Partitioned State (CHIPS).

Wenn wir im Kontext der Storage Access API über Drittanbieter-Cookies sprechen, meinen wir implizit unpartitionierte Drittanbieter-Cookies.

Funktionsweise

Drittanbieter-Inhalte, die in einem <iframe> eingebettet sind und auf Cookies oder anderen unpartitionierten Status zugreifen müssen, können den Zugriff mit der Storage Access API wie folgt anfordern:

1. Document.hasStorageAccess() kann aufgerufen werden, um zu überprüfen, ob die eingebetteten Inhalte bereits Zugriff auf unpartitionierte Cookies haben.

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

   Je nach Browser wird der Benutzer auf leicht unterschiedliche Weise gefragt, ob er die Berechtigung für die anfragende Einbettung erteilen möchte.

   • Safari zeigt Eingabeaufforderungen für alle eingebetteten Inhalte an, die vorher keinen Speicherzugriff erhalten haben.
   • Firefox fordert Benutzer nur auf, nachdem ein Ursprung auf mehr als einer Mindestanzahl von Websites Speicherzugriff angefordert hat.
   • Chrome zeigt Eingabeaufforderungen für alle eingebetteten Inhalte an, die vorher keinen Speicherzugriff erhalten haben. Es wird jedoch automatisch Zugriff gewährt und Eingabeaufforderungen übersprungen, wenn die eingebetteten Inhalte und die einbettende Seite Teil derselben related website set sind.

3. Die Berechtigung wird basierend darauf gewährt oder abgelehnt, ob der Inhalt alle Sicherheitsanforderungen erfüllt – siehe Sicherheitsüberlegungen für allgemeine Anforderungen und Browserspezifische Variationen für einige browserspezifische Sicherheitsanforderungen. Die versprochene Natur von requestStorageAccess() ermöglicht es Ihnen, Code auszuführen, um Erfolgs- und Fehlerfälle zu behandeln.

   Sobald die Berechtigung erteilt wurde, wird ein Berechtigungsschlüssel mit der Struktur <oberste Website, eingebettete Website> im Browser gespeichert. Wenn die einbettende Website beispielsweise embedder.com ist und die Einbettung locator.example.com, wäre der Schlüssel <embedder.com, example.com>.

   Dies bedeutet, dass die Berechtigung für den Zugriff auf unpartitionierte Cookies für jede Seite auf der example.com-Site oder einen ihrer Subdomains erteilt wird, die in einer Seite auf der embedder.com-Site eingebettet ist. docs.example.com, profile.example.com können jetzt beispielsweise requestStorageAccess() aufrufen, und das Versprechen würde automatisch erfüllt.

   Hinweis: Ältere Spezifikationsversionen verwendeten die spezifischere Berechtigungsschlüsselstruktur <oberste Website, eingebetteter Ursprung>, was bedeutete, dass dieselbe Site, cross-origin Einbettungen nicht mit dem Berechtigungsschlüssel übereinstimmten und den gesamten Prozess separat durchlaufen mussten.

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

   Wenn eine Einbettung eine Berechtigung erhält, wird diese Berechtigung auch für den aktuellen Kontext aktiviert. Andere Kontexte, wie andere Browser-Tabs oder Inhalte in anderen <iframe> Elementen auf der Seite, haben jedoch ihren Drittanbieter-Cookie-Zugriff standardmäßig blockiert. Das bedeutet, dass auch wenn eine Berechtigung erteilt wird, die Seite geladen und requestStorageAccess() aufgerufen werden muss, um die Berechtigung zu aktivieren. Wenn die Berechtigung bereits gewährt wurde, benötigt ein Aufruf von requestStorageAccess() keine transient activation und das Versprechen wird automatisch erfüllt.

   Die einzige Ausnahme vom "standardmäßig blockierten" Verhalten ist, wenn eine Einbettung eine gleichursprüngige Navigation durchführt, um sich nach der Gewährung oder Aktivierung einer Berechtigung neu zu laden. In solchen Fällen wird der Speicherzugriff aus der vorherigen Navigation übernommen. Dies ermöglicht es der eingebetteten Ressource, sich neu zu laden und Zugriff auf ihre Cookies zu erhalten.

   Hinweis: In älteren Spezifikationsversionen war der Zugriff pro Seite (Safari ist der einzige Browser, der dieses Modell noch verwendet). Wenn eine Einbettung über requestStorageAccess() Drittanbieter-Cookie-Zugriff erhielt, erhielten alle anderen Einbettungen derselben Site automatisch Zugriff. Dies war aus Sicherheitsgründen kein wünschenswertes Verhalten — zum Beispiel, wenn shop.example.com locator.users.com einbettet, um Benutzern zu ermöglichen, ihre Standortinformationen beim Einkaufen zu verwenden, und locator.users.com requestStorageAccess() aufruft, könnten shop.example.com und alle anderen eingebetteten Websites auf dessen Cookies zugreifen, aber auch auf Cookies von private.users.com, welche nicht eingebettet werden sollten. Erfahren Sie mehr über die Beweggründe hinter dieser Änderung.

5. Nachdem eine Einbettung die Speicherzugriffsberechtigung aktiviert hat, sollte sie sich neu laden. Der Browser fordert die Ressource erneut an, diesmal mit beinhalteten Drittanbieter-Cookies, und stellt sie der eingebetteten Ressource zur Verfügung, sobald sie geladen ist.

Storage access headers

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

Die storage access headers ermöglichen einen Workflow, bei dem der Server anfordern kann, dass die Berechtigung für den Kontext aktiviert wird. Auf diese Weise kann eine unnötige zusätzliche Last der eingebetteten Ressource vermieden werden, wenn 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 der Anfrage den Header Sec-Fetch-Storage-Access hinzu, um den Speicherzugriffsstatus des aktuellen Anforderungs-Kontexts anzuzeigen, z.B., ob die Berechtigung aktiviert, gewährt oder nicht gewährt wurde.
• Je nach Speicherzugriffsstatus der Anfrage kann der Server mit einem Header Activate-Storage-Access antworten, um zu verlangen, dass der Browser die Berechtigung für den Kontext aktiviert und die Anfrage mit Cookies wiederholt (um zu vermeiden, dass die Ressource geladen werden muss, um requestStorageAccess() aufzurufen, um denselben Effekt zu erzielen) oder die Berechtigung aktiviert und die zurückgegebene Ressource lädt.

Die storage access headers können auch verwendet werden, um die Berechtigung für passive Ressourcen zu aktivieren, z.B. Bilder, vorausgesetzt der Kontext hat bereits die Berechtigung erhalten. Dies könnte zum Beispiel verwendet werden, um verschiedene Bilder für verschiedene Benutzer, Zielgruppen oder Regionen anzubieten.

Die Workflows sind im Abschnitt Storage access header sequences dargestellt.

Anfrage-/Antwortfluss

JavaScript-Abfolgen

Betrachten Sie das Beispiel einer in einem <iframe> geladenen Bibliothek, die über eine Reihe von Websites hinweg geteilt werden muss und auf in unpartitionierten Cookies gespeicherte Anmeldeinformationen angewiesen ist.

Zunächst betrachten wir den Fall, in dem die Berechtigung nicht gewährt wurde:

1. Der Browser fordert die Ressource an, ohne Drittanbieter-Cookies einzuschließen.

2. Der Server antwortet mit einer "Fallback"-Version von Inhalten, die nicht auf Anmeldeinformationen angewiesen ist und die beim Laden keinen Zugriff auf ihre Cookies hat.

   • Nach dem Laden ruft die Ressource requestStorageAccess() mit transient activation auf, um die Berechtigung für den storage-access anzufordern und zu aktivieren.
   • Wenn die Berechtigung gewährt wird, lädt die Ressource sich selbst neu.

3. Der Browser fordert die Ressource erneut an, diesmal einschließlich der Drittanbieter-Cookies.

4. Die Serverantwort enthält eine "mit Anmeldeinformationen ausgestattete" Version der Ressource.

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

Nun betrachten wir den Fall, dass die Berechtigung gewährt, 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 derselben Website einzubetten.

Der Workflow ist fast identisch, da die Ressource immer noch zuerst 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-Abfolgen

Die storage access headers ermöglichen einen verbesserten Workflow, bei dem der Server anfordern kann, dass der Browser eine bereits gewährte Berechtigung aktiviert und die Anfrage mit enthaltenen Cookies wiederholt. Dies vermeidet die Anforderung, die Ressource zu laden, um requestStorageAccess() aufzurufen, wenn der Benutzer bereits die Berechtigung erteilt hat.

Der Sec-Fetch-Storage-Access-Header wird Anfragen hinzugefügt, um den Speicherzugriffsstatus des aktuellen Anforderungs-Kontexts anzuzeigen, wie z.B., ob die Berechtigung aktiviert, gewährt oder nicht gewährt wurde. Je nach Speicherzugriffsstatus der Anfrage kann der Server mit dem Header Activate-Storage-Access antworten, um zu verlangen, dass der Browser die Berechtigung für den Kontext aktiviert und die Anfrage mit Cookies wiederholt.

Schauen wir uns zunächst den Fall an, in dem versucht wird, eine eingebettete Ressource für einen neuen Kontext zu laden, der bereits die Berechtigung erhalten hat:

1. Der Browser sendet eine Anfrage mit Sec-Fetch-Storage-Access: inactive, um anzuzeigen, dass die Berechtigung für den Kontext gewährt, aber inaktiv ist.
   • Die Anfrage enthält auch den Origin-Header, um dem Server zu helfen zu entscheiden, ob er die Berechtigung aktivieren möchte.
2. Der Server kann dann mit Activate-Storage-Access: retry antworten, um anzuzeigen, dass der Browser die Berechtigung aktivieren und die Anfrage mit Cookies wiederholen soll.
   • Die Antwort sollte auch den Vary: Sec-Fetch-Storage-Access enthalten, da sie vom Wert Sec-Fetch-Storage-Access abhängt.
   • Beachten Sie, dass die Antwort keinen Inhalt enthält.
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, was dem Browser mitteilt, die neue Version der Bibliothek mit Zugriff auf Drittanbieter-Cookies zu laden.

Der letzte zu berücksichtigende Zustand ist, wenn eine eingebettete Ressource geladen wird, für die die Berechtigung nicht gewährt wurde:

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

2. Der Server antwortet dann mit der Ressource, die beim Laden die Berechtigung für den sicheren Zugriff mit transient activation anfordert. Der Activate-Storage-Access-Header wird in die Antwort nicht aufgenommen, aber der Server sollte Vary: Sec-Fetch-Storage-Access hinzufügen.

   Nachdem der Benutzer die Berechtigung erteilt (und damit aktiviert) hat, lädt sich die Einbettung neu.

3. Der Browser fügt Sec-Fetch-Storage-Access: active zur Anfrage hinzu, um anzuzeigen, dass der Kontext eine aktivierte Speicherzugriffsberechtigung hat, und schließt die Drittanbieter-Cookies ein.

4. Der Server antwortet mit Activate-Storage-Access: load, was dem Browser mitteilt, die neue Version der Bibliothek mit Zugriff auf Drittanbieter-Cookies zu laden.

Sicherheitsüberlegungen

Verschiedene Sicherheitsmaßnahmen könnten dazu führen, dass ein Aufruf von Document.requestStorageAccess() fehlschlägt. Prüfen Sie die folgende Liste, wenn Sie Probleme haben, eine Anfrage erfolgreich zu gestalten:

1. Der Berechtigungsantrag muss mit einer Benutzergeste (transient activation) wie einem Tippen oder Klicken verbunden sein. Dies verhindert, dass eingebettete Inhalte auf der Seite den Browser oder Benutzer mit übermäßigen Zugriffsanfragen spammen. Beachten Sie, dass dies nicht erforderlich ist, wenn:

   • Die API-Berechtigung bereits für einen anderen Kontext mit demselben <oberste Website, eingebettete Website>-Schlüssel erteilt wurde.
   • Der Aufrufer ein oberstes Dokument oder eine gleiche Site wie das oberste Dokument ist. In solchen Fällen muss requestStorageAccess() wahrscheinlich überhaupt nicht aufgerufen werden.

2. Das Dokument und das oberste Dokument dürfen keinen null Ursprung haben.

3. Ursprünge, mit denen nie als Erstparteie interagiert wurde, haben kein Konzept von Erstparteiespeicher. Aus Sicht der Benutzer haben sie nur eine Drittpartei-Beziehung zu diesem Ursprung. Zugriffsanfragen werden automatisch abgelehnt, wenn der Browser erkennt, dass der Benutzer kürzlich nicht im Erstparteie-Kontext mit den eingebetteten Inhalten interagiert hat (in Firefox bedeutet "kürzlich" innerhalb von 30 Tagen).

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 handeln, stellt die API den allow-storage-access-by-user-activation sandbox token bereit. Das <iframe> muss dies enthalten, um Speicherzugriffsanfragen zu ermöglichen, zusammen mit allow-scripts und allow-same-origin, damit es ein Skript ausführen kann, um die API aufzurufen und sie in einem Ursprung auszuführen, der Cookies/Zustand haben kann:

   html

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

6. Die Verwendung dieser Funktion kann durch eine storage-access Permissions Policy blockiert werden, die auf Ihrem Server eingestellt ist.

Browserspezifische Variationen

Obwohl die API-Oberfläche gleich ist, sollten Websites, die die Storage Access API verwenden, Unterschiede im Grad und Umfang des Zugriffs auf Drittanbieter-Cookies erwarten, den sie zwischen verschiedenen Browsern erhalten, aufgrund der Unterschiede in deren Speicherzugriffspolitiken.

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 Speicherzugriffsberechtigungen werden nach 30 Tagen ohne Benutzerinteraktion im Browser schrittweise entfernt. Die Interaktion mit den eingebetteten Inhalten verlängert diese Grenze um weitere 30 Tage. Dies tritt nicht auf, wenn Document.requestStorageAccessFor() aufgerufen wird, da sich der Benutzer bereits auf der Seite befindet.

Firefox

• Wenn der eingebettete Ursprung tracker.example bereits Drittanbieter-Cookie-Zugriff auf den obersten Ursprung foo.example erhalten hat und der Benutzer eine Seite von foo.example besucht, die eine Seite von tracker.example erneut einbindet, kann der eingebettete Ursprung sofort Drittanbieter-Cookie-Zugriff beim Laden haben, wenn dieser Besuch vor weniger als 30 Tagen stattfand.
• Die Speicherzugriffsberechtigungen werden nach Ablauf von 30 Kalendertagen schrittweise entfernt.

Die Dokumentation zur neuen Speicherzugriffspolitik von Firefox zum Blockieren von Tracking-Cookies enthält eine detaillierte Beschreibung des Umfangs der Speicherzugriffsberechtigungen.

Safari

• Die Speicherzugriffsberechtigungen werden nach 30 Tagen ohne Benutzerinteraktion im Browser schrittweise aufgehoben. Der erfolgreiche Einsatz der Storage Access API setzt diesen Zähler zurück.

Beispiele

• Siehe Verwendung der Storage Access API für einen Implementierungs-Leitfaden mit Codebeispielen.

API-Methoden

Document.hasStorageAccess()

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

Document.hasUnpartitionedCookieAccess()

Neuer Name für Document.hasStorageAccess().

Document.requestStorageAccess()

Erlaubt Inhalten, die in einem Drittanbieter-Kontext geladen sind (d.h. eingebettet in ein <iframe>), Zugriff auf Drittanbieter-Cookies und unpartitionierten Status anzufordern; gibt ein Promise zurück, das sich auflöst, wenn der Zugriff gewährt wurde, und ablehnt, wenn der Zugriff verweigert wurde.

Document.requestStorageAccessFor() Experimentell

Ein vorgeschlagener Erweiterung der Storage Access API, die es obersten Websites ermöglicht, den Zugriff auf Drittanbieter-Cookies im Namen von eingebetteten Inhalten von einer anderen Website in derselben related website set anzufordern. Gibt ein Promise zurück, das sich auflöst, wenn der Zugriff gewährt wurde, und ablehnt, wenn der Zugriff verweigert wurde.

interaktion erfordern, ohne einen zweiten Klick zu verlangen. Beispielsweise könnte ein Aufrufer ein Popup-Fenster von dem aufgelösten Versprechen aus öffnen, ohne Firefox' Pop-Up-Blocker auszulösen.

Ergänzungen zu anderen APIs

Permissions.query(), der "storage-access" Funktionsname

In unterstützenden Browsern kann dies abfragen, ob der Drittanbieter-Cookie-Zugriff im Allgemeinen gewährt wurde, d.h. an eine andere Same-Site-Einbettung. Ist dies der Fall, können Sie requestStorageAccess() ohne Benutzerinteraktion aufrufen, und das Versprechen wird automatisch aufgelöst.

Permissions.query(), der "top-level-storage-access" Funktionsname Experimentell

Ein separater Funktionsname, der verwendet wird, um abzufragen, ob die Berechtigung für den Zugriff auf Drittanbieter-Cookies bereits über requestStorageAccessFor() gewährt wurde. In diesem Fall müssen Sie requestStorageAccessFor() nicht erneut aufrufen.

Ergänzungen zu HTTP

Permissions-Policy

Permissions-Policy: storage-access

Die storage-access Permissions-Policy-Direktive kontrolliert, ob ein in einem Drittanbieter-Kontext geladenes Dokument (d.h. eingebettet in ein <iframe>) die Speicherzugriffs-API verwenden darf, um Zugriff auf unpartitionierte Cookies anzufordern.

Storage access headers

Sec-Fetch-Storage-Access

Gibt den "Speicherzugriffstatus" für den aktuellen Anforderungs-Kontext an, der einer von none, inactive oder active sein wird.

Activate-Storage-Access

Wird als Antwort auf Sec-Fetch-Storage-Access verwendet, um anzuzeigen, dass der Browser eine bestehende Berechtigung für sicheren Zugang aktivieren und die Anfrage mit Cookies erneut ausführen kann oder eine Ressource mit Cookie-Zugang 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

• Using the Storage Access API
• Introducing Storage Access API (WebKit Blog)