files/en-us/web/api/document/requeststorageaccess/index.md
{{APIRef("Storage Access API")}}
The requestStorageAccess() method of the {{domxref("Document")}} interface allows content loaded in a third-party context (i.e., embedded in an {{htmlelement("iframe")}}) to request access to third-party cookies and unpartitioned state.
This is relevant to user agents that, by default, block access to third-party, unpartitioned cookies to improve privacy (e.g., to prevent tracking), and is part of the Storage Access API.
To check whether permission to access third-party cookies has already been granted, you can call {{domxref("Permissions.query()")}}, specifying the feature name "storage-access".
After an embed has activated storage-access permission via requestStorageAccess(), it should reload itself.
The browser will re-request the resource with third-party unpartitioned cookies included, and make them available to the embedded resource once it has loaded.
Third-party cookies are sent only with requests to the embedded resource's exact origin.
Other origins within the same site that wish to access their third-party cookies will need to activate the granted storage-access permission.
The storage access headers should be used for activating a granted storage-access permission.
Note that the headers can activate a granted permission for any embedded resource, such as credentialed images, not just code embedded in an {{htmlelement("iframe")}}.
It is also possible to activate a granted permission for a cross-origin, same-site endpoint by calling requestStorageAccess() (this time without the requirement for transient activation).
However, this only works to activate permission for embedded code.
It is also less efficient than using the headers, because the resource needs to be loaded in order to activate the permission.
[!NOTE] Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} Permissions Policy set on your server. In addition, the document must pass additional browser-specific checks such as allowlists, blocklists, on-device classification, user settings, anti-clickjacking heuristics, or prompting the user for explicit permission.
requestStorageAccess()
requestStorageAccess(types)
types {{optional_inline}}
false. Available properties are as follows:
all
cookies
sessionStorage
localStorage
indexedDB
locks
caches
getDirectory
estimate
createObjectURL
revokeObjectURL
BroadcastChannel
SharedWorker
A {{jsxref("Promise")}} that fulfills with undefined if the access to third-party cookies was granted and no types parameter was provided, fulfills with {{domxref("StorageAccessHandle")}} if the access to unpartitioned state requested by the types parameter was provided, and rejects if access was denied.
requestStorageAccess() requests are automatically denied unless the embedded content is currently processing a user gesture such as a tap or click ({{Glossary("transient activation")}}), or unless permission was already granted previously. If permission was not previously granted, they need to be run inside a user gesture-based event handler. The user gesture behavior depends on the state of the promise:
requestStorageAccess() in a loop until the user accepts the prompt.InvalidStateError {{domxref("DOMException")}}
types parameter is provided and all of its properties are false.NotAllowedError {{domxref("DOMException")}}
null origin.allow-storage-access-by-user-activation token is not set.document.requestStorageAccess().then(
() => {
console.log("cookie access granted");
},
() => {
console.log("cookie access denied");
},
);
document.requestStorageAccess({ localStorage: true }).then(
(handle) => {
console.log("localStorage access granted");
handle.localStorage.setItem("foo", "bar");
},
() => {
console.log("localStorage access denied");
},
);
[!NOTE] See Using the Storage Access API for a more complete example.
{{Specifications}}
{{Compat}}