Wiki · Concept · Last reviewed June 25, 2026

Storage Access API

The Storage Access API is a browser privacy API for letting embedded third-party content request controlled access to unpartitioned storage, including cookies, when the user agent would otherwise block or partition that state.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, storage access, cookies, agents, web governance

Definition

The Storage Access API is specified by the Privacy Community Group as a way for content embedded in a third-party context, commonly an iframe, to ask for access to unpartitioned website data such as cookies. The specification defines unpartitioned data as client-side storage available to a site in its first-party-site context. A third-party context is the inverse: the embedded document is not running as the first-party site of the top-level page.

The API exists because silent third-party storage has been a privacy and governance problem. Login buttons, comments, payment frames, media embeds, and account widgets can need continuity across sites, but the same ambient state can also support cross-site tracking. Storage access turns that boundary into a browser-mediated event: the embedded party must ask, the user agent applies policy, and the grant is scoped rather than assumed.

The primary document is not itself a W3C standards-track Recommendation or a WHATWG Living Standard. The Privacy Community Group draft says the work is intended for merger into the HTML Living Standard. Reviewers should therefore treat it as live browser platform work and verify the specific user agent behavior they depend on.

Mechanism

The core methods are Document.hasStorageAccess() and Document.requestStorageAccess(). hasStorageAccess() checks whether the document currently has access to unpartitioned data. In a non-secure context, the specification resolves that check as false. requestStorageAccess() asks the user agent to grant access; in a non-secure context, the specification rejects the request with a NotAllowedError.

The grant path is controlled by browser policy, user settings, frame context, and web permissions. The specification defines a storage-access permission and integrates with Permissions Policy. A frame can also be constrained by sandboxing: the sandbox token allow-storage-access-by-user-activation is relevant when an embedded document needs to request access from a sandboxed iframe. User activation matters because the feature is meant to preserve contextual choice rather than restore invisible third-party cookie behavior.

A grant should not be read as an unlimited storage pass. The specification describes request behavior after access is granted, including same-origin boundaries for unpartitioned cookies. It is a tool for one embedded origin to recover necessary first-party continuity in a particular context, not a general license for arbitrary third-party fetches or cross-site state sharing.

Agent Context

For AI Browsers and Computer Use, the Storage Access API is a small but important boundary. Browser agents may render login widgets, support consoles, payment providers, embedded dashboards, and account-recovery flows while acting on behalf of a user. When one of those frames asks for storage access, the event is not the same thing as the agent's own authorization, and it is not proof that the user intended every downstream action.

Agent review should distinguish three layers: the top-level site the agent is visiting, the embedded origin requesting storage, and the user or organization whose session state may become visible again. A responsible agent runtime should preserve evidence of the request, show the origin plainly where a human decision is required, and avoid treating browser permission prompts as routine obstacles to click through.

Governance Use

Storage access review belongs with identity, privacy, and automation controls. A governance record should capture the top-level site, embedded origin, secure-context status, iframe sandbox flags, Permissions-Policy state, the method called, the request result, and the category of storage involved. It should also state why the embedded party needs unpartitioned state: sign-in, fraud prevention, account linking, payments, comments, personalization, analytics, or something else.

The API pairs with Federated Credential Management, Referrer Policy, Fetch Metadata Request Headers, Data Minimization, and Contextual Integrity. Those mechanisms answer different questions: who is asking, what request context crossed the boundary, how much data should move, and whether the use matches the social setting.

Limits

The Storage Access API is not authentication, consent management, identity proofing, authorization, bot detection, or a complete tracking-prevention system. A granted request may restore cross-site state that is legitimate for a login flow and still excessive for a marketing or analytics frame. A denied request may break a useful embed but protect the user's expectation that one site should not remember them everywhere.

Browser support and behavior can vary across products and releases, so implementation claims should be checked against current browser documentation and live tests. A site that depends on this API should also design a fallback path for blocked, denied, unsupported, or sandboxed cases.

Review Record

Source Discipline

Claims about method names, secure-context behavior, unpartitioned data, third-party contexts, sandbox integration, and permission policy should cite the Privacy Community Group specification. Claims about practical browser behavior should cite current browser documentation or be verified with a test in the browser under review. Do not collapse Storage Access into FedCM, cookie partitioning, or a general anti-tracking feature; those systems overlap but have different control surfaces.

Spiralist Reading

Spiralism reads the Storage Access API as a lesson in bounded memory. Not every embed deserves to remember the visitor. When memory is necessary, the request should be named, scoped, logged, and made accountable to the human context that gave it meaning.

Sources

Return to Wiki