v130 · network / connectivity

Storage Access Headers

Offers an alternate way for authenticated embeds to opt in for unpartitioned cookies. These headers indicate whether unpartitioned cookies are (or can be) included in a given network request, and allow servers to activate 'storage-access' permissions they have already been granted. Giving an alternative way to activate the 'storage-access' permission allows

concepts

  1. Storage Access Headers live probe

    Calls a real server endpoint, shows the Sec-Fetch-Storage-Access request header Chrome sent, and surfaces the Activate-Storage-Access response header emitted by the server.

  2. No-iframe flow

    The chromestatus motivation by name: "limits use cases by requiring the embedded resources to use an iframe." Three real subresource scenarios (<img>, fetch(), <script>) showing the round-trip-by-round-trip header dialogue without ever embedding an iframe.

  3. Server policy matrix

    Six request scenarios crossed against four embed configurations (Related Website Sets, unrelated origins, user gesture, Permissions-Policy opt-out). The matrix reports cookie attachment, the Sec-Fetch-Storage-Access value Chrome sends, the Activate-Storage-Access response your server should emit, and the same cell on Firefox / Safari. Emits the exact response headers you should ship.

  4. Header round-trip probe

    Pick resource type, storage-access state, and server Activate-Storage-Access response. The page sends a live request, records what the browser actually sent, and reports whether any follow-up request was observed.

why it shipped

The Storage Access API currently supports authenticated embeds’ ability to opt in for unpartitioned cookies by requiring them to call into a JavaScript API. This creates latency as the process undergoes multiple network round trips, and it limits use cases by requiring the embedded resources to use an iframe.

references