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 cookies and, in some browser surfaces, other unpartitioned state when the user agent would otherwise block or partition it.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: 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. The draft defines unpartitioned data as client-side storage that would be available to a site in its first-party-site context; a third-party context is one where the embedded document is not in that first-party-site context.

The original and still central case is cookies. Login buttons, comments, payment frames, media embeds, and account widgets can need their own first-party cookies while embedded elsewhere, but the same ambient state can also support cross-site tracking. Storage access turns that boundary into a browser-mediated event: the embedded party asks, the user agent applies policy, and any grant is scoped instead of assumed.

The API is not a consent system, identity proof, authorization framework, or general exception to browser privacy boundaries. It is a controlled way for an embedded origin to regain access to its own unpartitioned state in a specific top-level context. The main PrivacyCG draft is live platform work rather than a W3C Recommendation or WHATWG Living Standard, so implementation claims should name the browser and version being relied on.

Snapshot

Current Context

As of June 25, 2026, Storage Access API remains a live browser-privacy mechanism for sites affected by third-party-cookie blocking, partitioned storage, private browsing, tracking protection, or enterprise policy. Google Privacy Sandbox says the API is available in major browsers but has implementation differences, while the PrivacyCG draft continues to describe standardization work intended for integration with other web-platform specifications.

Chrome's third-party-cookie roadmap changed in 2025. Google announced on April 22, 2025 that it would maintain its current third-party-cookie choice approach in Chrome and would not roll out a new standalone third-party-cookie prompt, while continuing tracking protections such as Incognito-mode blocking. That means Storage Access API is not simply a post-cookie replacement; it remains relevant wherever a browser, user, mode, or policy blocks or partitions third-party state.

The surrounding toolkit has shifted. CHIPS / Partitioned Cookies scopes a cookie to a top-level site. Federated Credential Management targets federated sign-in flows. Related Website Sets is now best treated as discontinued Chrome Privacy Sandbox infrastructure, so current Storage Access API review should not assume RWS-based prompt reduction or requestStorageAccessFor() behavior unless the target browser still documents it.

Mechanism

The core methods are Document.hasStorageAccess() and Document.requestStorageAccess(). hasStorageAccess() checks whether the current document can access unpartitioned state; the PrivacyCG algorithm resolves false in a non-secure context. requestStorageAccess() asks the user agent for access; in a non-secure context, or when blocked by policy, opaque origins, sandboxing, or permission denial, the request can reject with 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 sandboxed frame must be allowed to request storage access, using the allow-storage-access-by-user-activation sandbox token where required. User activation matters because the feature is meant to preserve contextual choice rather than restore invisible third-party cookie behavior.

MDN documents an optional types parameter for requestStorageAccess(). Without a types parameter, a successful request grants third-party cookie access and returns undefined. With a types parameter, a successful request can return a StorageAccessHandle for requested unpartitioned state, such as localStorage, indexedDB, caches, locks, directories, object URLs, BroadcastChannel, and SharedWorker. Because browser support varies, audits should record which storage type was requested and which browser actually provided it.

A grant should not be read as an unlimited storage pass. MDN notes that third-party cookies are sent only to the embedded resource's exact origin after activation; other origins within the same site need their own activation. Storage access 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.

Storage Access Headers

The companion Storage Access Headers draft defines Sec-Fetch-Storage-Access, a request header with none, inactive, and active states, and Activate-Storage-Access, a response header with load and retry flows. The purpose is operational: when permission already exists, the server can ask the browser to activate it and avoid an extra round trip where an iframe first loads without cookies just to call JavaScript.

Those headers should not be treated as consent, authentication, or an authorization decision by the server. They communicate browser storage-access state for a fetch context. A server that varies credentialed responses by Sec-Fetch-Storage-Access should treat it as cache-relevant request metadata and should still apply ordinary authentication, authorization, CSRF, and data-minimization controls.

Boundary Tests

Not CHIPS. CHIPS stores a cookie separately per top-level site. Storage Access API asks for access to unpartitioned state in a third-party context.

Not FedCM. Federated Credential Management is a browser-mediated federated-login flow. Storage Access API can support post-login embedded continuity, but it is not itself a sign-in protocol.

Not RWS. Related Website Sets was a domain-relationship mechanism used with Storage Access API in Chrome. Its retirement changes the practical review posture for any design that assumed automatic prompt reduction across declared related domains.

Not SameSite or CORS. Storage access does not erase SameSite, same-origin policy, CORS, Fetch Metadata, or application authorization duties.

Not consent. A granted browser permission or header activation does not prove that the user understood every downstream data use, especially in ads, analytics, embedded identity, or automated browser-agent workflows.

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.

The most important failure is hidden continuity. After storage access is activated, an embedded service may load a signed-in or personalized state that the agent did not create during the visible session. Agent logs should therefore record the top-level origin, embedded origin, method or header path, requested storage type, visible user gesture, permission result, and whether the recovered state was used for purchases, messages, account changes, identity proofing, or support actions.

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, method or header path, request result, requested storage type, browser/version, and fallback behavior. 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, Content Security Policy, Data Minimization, and Contextual Integrity. Those mechanisms answer different questions: who is asking, what request context crossed the boundary, what the page may load, how much data should move, and whether the use matches the social setting.

For regulated or high-risk contexts, the review should ask whether the same purpose can be met with partitioned cookies, a first-party redirect, FedCM, a short-lived signed token, or no cross-site continuity at all. If unpartitioned state is necessary, the record should name retention limits, visible user notice, revocation path, denied-state behavior, and whether the storage-access event is included in AI Audit Trails or security logs.

Failure Modes

Prompt laundering. A product treats a browser permission prompt as if it were consent to all cross-site data use.

Header confusion. A server reads Sec-Fetch-Storage-Access: active as an authorization signal instead of storage-state metadata.

Overbroad state restoration. An embed requests more unpartitioned state than the user-facing workflow requires.

Agent click-through. An automated browser agent clicks a storage-access prompt without preserving human intent or origin evidence.

RWS assumption drift. A design still assumes Related Website Sets or requestStorageAccessFor() behavior after the relevant Chrome Privacy Sandbox path was retired or deprecated.

Cache leak. A credentialed response varies by storage-access state but the server or intermediary cache does not vary correctly on the relevant request header.

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. Safari and WebKit historically emphasized cookie access under Intelligent Tracking Prevention; MDN and Chrome documentation describe broader non-cookie handles and storage-access headers; standards text may lag or differ from shipped behavior. A site that depends on this API should therefore design a fallback path for blocked, denied, unsupported, sandboxed, or header-incompatible cases.

Review Record

Source Discipline

Claims about method names, secure-context behavior, unpartitioned data, third-party contexts, sandbox integration, and permission-policy integration should cite the Privacy Community Group Storage Access API draft. Claims about non-cookie types, StorageAccessHandle, Baseline status, and exception behavior should cite current MDN or browser-vendor documentation and be verified in the browser under review.

Claims about Sec-Fetch-Storage-Access, Activate-Storage-Access, none/inactive/active, load/retry, Origin, and cache handling should cite the Storage Access Headers draft. Claims about Chrome's current third-party-cookie posture should cite Google Privacy Sandbox's April 22, 2025 announcement rather than older phase-out language. Do not collapse Storage Access into FedCM, CHIPS, RWS, 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.

Open Questions

Sources

Return to Wiki