demo · v141
Origin vs Site
Before Chrome 141, granting Storage Access in chat.foo.com as an iframe would attach cookies to any request back to *.foo.com (the whole site). In 141, that grant only attaches cookies to requests back to chat.foo.com — strict origin. Scenarios table below covers every common cross-origin same-site pattern.
try the origin scope
Choose the iframe origin that received a Storage Access grant, then choose a fetch target. The readout compares Chrome <=140's site-wide cookie scope with Chrome 141's strict-origin scope.
Frame origin granted storage access: https://chat.foo.com. The table shows whether each subsequent fetch from that frame carries cookies:
the call
// Inside an iframe on chat.foo.com embedded by example.com
await document.requestStorageAccess(); // user prompts, accepts
// Chrome ≤ 140: cookies sent to *.foo.com on cross-origin same-site requests
fetch("https://api.foo.com/me", { credentials: "include" }) // had cookies
fetch("https://chat.foo.com/me", { credentials: "include" }) // had cookies
// Chrome 141+: cookies only for requests back to chat.foo.com
fetch("https://api.foo.com/me", { credentials: "include" }) // no cookies (3p)
fetch("https://chat.foo.com/me", { credentials: "include" }) // cookies
why this angle
The chromestatus entry frames this as "improving security without affecting privacy boundaries". The decision matrix below makes the change concrete: most sites don't notice; a few that fan cookies out to api.foo.com, cdn.foo.com, media.foo.com from a single embedded widget will see auth break. The Storage Access Headers feature is the migration path, but understanding which requests change behaviour is the first step.