Sec-Fetch-Storage-Access

Embedded cross-site content needing cookies once required a JavaScript round-trip before credentialed requests worked. The Sec-Fetch-Storage-Access request header removes the round-trip: browsers attach the header to cross-site requests, reporting whether the request context holds permission to use its unpartitioned cookies.

Table of Contents

Usage

The header rides on cross-site requests for embedded content, such as an authenticated widget in an iframe. Third-party cookie restrictions leave such embeds without their cookies until the user or the Storage Access API grants permission. Before the header existed, an embed had to load once without credentials, call document.requestStorageAccess() in script, and reload itself after the grant.

Sec-Fetch-Storage-Access tells the server where the request stands, and the companion Activate-Storage-Access response header lets the server act on the answer without any script in the embed. A server seeing inactive responds with Activate-Storage-Access: retry, and the browser repeats the request with storage access turned on and cookies attached. A server accepting the load as-is answers with Activate-Storage-Access: load.

The Sec- prefix marks the header as browser-controlled. Page script never sets the value, so the server reads the state as asserted by the browser rather than by the embedded document.

Values

none

The request context holds no storage access permission. The request carries no unpartitioned cookies, and activation is not available without a permission grant.

inactive

Permission exists but the context has not activated storage access, so the request still travels without unpartitioned cookies. The server invites a credentialed retry with Activate-Storage-Access: retry.

active

Storage access is active for the request context. The request includes the unpartitioned cookies, and no further activation is needed.

Example

An embedded document on a third-party site requests a resource from its own origin. Permission was granted earlier, so the browser reports inactive and the server asks for an activated retry.

Request

GET /widget/session HTTP/1.1
Host: embed.example.re
Sec-Fetch-Storage-Access: inactive
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: iframe

Response

HTTP/1.1 401 Unauthorized
Activate-Storage-Access: retry; allowed-origin="https://site.example.re"
Vary: Sec-Fetch-Storage-Access

The browser activates storage access and repeats the request with cookies, and the reported value moves to active. Responses varying on the header carry Vary: Sec-Fetch-Storage-Access so caches keep the credentialed and uncredentialed answers apart.

Crawlers and Sec-Fetch-Storage-Access

Verified crawler probe

Probe data from verified crawler traffic (September 2026 snapshot) shows which bots send Sec-Fetch-Storage-Access when requesting pages. Yes marks the header on at least nine of ten sampled requests from the bot, Sometimes marks a smaller share, and No marks absence.

Crawler Sends Sec-Fetch-Storage-Access
Amazonbot No
Applebot No
Baiduspider No
Bingbot No
ClaudeBot No
DuckDuckBot No
GPTBot No
Googlebot No
Googlebot (smartphone) No
Googlebot-Image No
Meta-ExternalAgent No
Meta-WebIndexer No
OAI-SearchBot No
SeznamBot No
YandexBot No
YandexFavicons No

See also

Last updated: September 21, 2026