The Storage Access API provides a way for embedded, cross-origin content to gain unrestricted access to storage that it would normally only have access to in a first-party context (we refer to this as an origin’s first-party storage). The API provides methods that allow embedded resources to check whether they currently have access to their first-party storage, and to request access to their first-party storage from the user agent.
Most browsers implement a number of storage access policies that restrict access to cookies and site data for embedded, cross-origin resources. These restrictions range from giving embedded resources under each top-level origin a unique storage space to outright blocking of storage access when resources are loaded in a third-party context.
The semantics around third-party cookie blocking policies in particular differ from browser to browser, but the core functionality is similar: cross-origin resources embedded in a third-party context are not given access to the same cookies and site storage that they would have access to when loaded in a first-party context.
These cookie blocking policies are known to break embedded cross-origin content that requires access to its first-party storage. As an example, federated logins often require access to authentication cookies stored in first-party storage, and will require the user to sign in on each site separately (or completely break) if those cookies are not available. In the case of breakage, site owners have often encouraged users to add their site as an exception or to disable the policy entirely. As a consequence, users who wish to continue to interact with embedded content are forced to greatly relax their blocking policy for resources loaded from all embedded origins and possibly across all websites.
The Storage Access API is intended to solve this problem; embedded cross-origin content can request unrestricted access to its first-party storage on a site-by-site basis via the
Document.requestStorageAccess() method, and check whether it already has access via the
In addition, sandboxed
<iframe>s cannot be granted storage access by default for security reasons. The API therefore also adds the
allow-storage-access-by-user-activation sandbox token. The embedding website needs to add this to allow storage access requests to be successful, along with
allow-same-origin to allow it to call the API, and execute in an origin that can have cookies:
<iframe sandbox="allow-storage-access-by-user-activation allow-scripts allow-same-origin"> ... </iframe>
The API is designed to limit the potential storage exceptions to origins for which the user has shown an intent to interact. This is enforced through the following constraints:
The browser may decide to involve the user in the decision of whether to grant an incoming storage access request. Specifics regarding the lifetime of a storage grant and the circumstances under which the browser may decide to inform the user are currently being worked through and will be announced once ready.
Although the API surface is the same, websites using the Storage Access API should expect differences in the level and extent of storage access they receive between Firefox and Safari. This is caused by differences in the storage access policies implemented in the two browsers. Design properties unique to Firefox are summarized here:
tracker.examplehas already obtained first-party storage access on the top-level origin
foo.example, and the user visits a page from
foo.exampleembedding a page from
tracker.exampleagain in less than 30 days, the embedded origin will have storage access immediately when loading.
foo.exampleembeds more than one
tracker.example, and one of those
<iframe>s uses the Storage Access API in order to obtain storage access successfully, all other iframes from
foo.exampletop-level origins will immediately gain storage access as well, without needing to call
tracker.examplehas previously successfully obtained storage access on top-level origin
foo.example, all embedded subresources from
foo.example(e.g. scripts, images, stylesheets, etc.) will load with access to their first-party storage, which means they may send Cookie headers and honor incoming
requestStorageAccess()is resolved, the embedded page will gain access to its entire first-party storage, not just cookies. This includes access to APIs such as Web Storage, IndexedDB, DOM Cache, and so on.
Documentation for Firefox's new storage access policy for blocking tracking cookies includes a detailed description of the scope of storage access grants.
The storage API methods are implemented on the
Promisethat resolves with a boolean value indicating whether the document has access to its first-party storage.
Promisethat resolves if the access to first-party storage was granted, and rejects if access was denied.
Note: User interaction propagates to the Promise returned by both of these methods, allowing the callers to take actions that require user interaction without requiring a second click from the user. For example, a caller could open a pop-up window from the resolved Promise without triggering Firefox’s pop-up blocker.
sandbox attribute has a new token,
allow-storage-access-by-user-activation, which permits sandboxed
<iframe>s to use the Storage Access API to request storage access.
The API is currently only at the proposal stage — the standardization process has yet to begin. You can currently find specification details of the API at Apple's Introducing Storage Access API blog post, and WHATWG HTML issue 338 — Proposal: Storage Access API.
No compatibility data found. Please contribute data for "api.Document.hasStorageAccess" (depth: 1) to the MDN compatibility data repository.
No compatibility data found. Please contribute data for "api.Document.requestStorageAccess" (depth: 1) to the MDN compatibility data repository.
© 2005–2018 Mozilla Developer Network and individual contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.