demo · v141

Storage Access Tester

Chrome 141 tightens the Storage Access API: document.requestStorageAccess() now grants cookies only to the exact same origin — not just the same site. Try the live API probe, walk the decision flowchart, and compare the before/after access matrix.

checking document.requestStorageAccess availability…
iframe origin: https://embed.example.com  ·  top-frame origin: https://www.example.com
Click a button above to test the live API. (Must be called from within an iframe context to resolve — this simulates the call.)

Origin pair access matrix

Same site ≠ same origin. These pairs all share the eTLD+1 example.com but differ in scheme, host, or port.

Pre-141 — site-keyed (loose)

iframe originrequest targetaccess
https://a.example.comhttps://a.example.comALLOW
https://a.example.comhttps://b.example.comALLOW
https://a.example.comhttps://example.comALLOW
https://a.example.com:8080https://a.example.comALLOW
http://a.example.comhttps://a.example.comALLOW
https://a.example.comhttps://other.comBLOCK

141+ — origin-keyed (strict)

iframe originrequest targetaccess
https://a.example.comhttps://a.example.comALLOW
https://a.example.comhttps://b.example.comBLOCK
https://a.example.comhttps://example.comBLOCK
https://a.example.com:8080https://a.example.comBLOCK
http://a.example.comhttps://a.example.comBLOCK
https://a.example.comhttps://other.comBLOCK

Highlighted rows: behaviour changed in Chrome 141.

Decision flowchart — Chrome 141

Does the iframe call document.requestStorageAccess()?

Is the page in a first-party context (top frame)? YES → resolve immediately (no-op).
Does the user agent have a prior permission grant for this origin? YES → resolve.
Is user activation present? NO → reject (NotAllowedError).
Show browser permission prompt. User denies? YES → reject.
Grant issued. Do cookies attach to same-origin requests from the iframe? YES → resolve.
141 change: "same-origin" means identical scheme + host + port. Requests to b.example.com from a.example.com are BLOCKED even if both are on example.com.

Migration guide

If your app relied on same-site (not same-origin) access

  1. Consolidate onto one subdomain. Move both your embed and API onto the exact same origin (https://embed.example.com → https://embed.example.com/api/…). requestStorageAccess grants stay intact.
  2. Use Storage Access headers. The Sec-Fetch-Storage-Access / Activate-Storage-Access header handshake lets you opt individual origins back in without a new prompt. See the Migration with Storage Access Headers demo.
  3. Enterprise: CookiesAllowedForUrls policy. Managed deployments can whitelist specific cross-origin pairs via Chrome enterprise policy — no code change required.
  4. Use partitioned cookies (CHIPS). If you control the third-party embed, opt into cookie partitioning with Partitioned attribute — avoids the SAA flow entirely.

the API call

// Inside an iframe at https://embed.example.com
// (requires prior user gesture in 141+)

// Basic — attaches unpartitioned cookies to same-ORIGIN requests only:
await document.requestStorageAccess();

// Selective — request specific storage types:
await document.requestStorageAccess({
  cookies: true,
  localStorage: false,
  sessionStorage: false,
});

// Check without prompting:
const hasAccess = await document.hasStorageAccess();
console.log(hasAccess); // true/false

// 141: cookies only flow to requests where
//   requestUrl.origin === iframe.origin
//   i.e. same scheme + host + port — NOT just same site.

see also