Sec-Fetch-Storage-Access: HTTP Header for Storage Access Status

Understanding Sec-Fetch-Storage-Access

The Sec-Fetch-Storage-Access HTTP request header provides the "storage access status" for the current fetch context. It was introduced as part of the Storage Access API HTTP headers specification to enable embedded cross-site content to access unpartitioned cookies without requiring JavaScript execution.

This fetch metadata header automatically tells servers whether an embedded cross-site request has storage access permission, enabling server-side control over cookie access without the performance overhead of JavaScript-based Storage Access API calls. The header was shipped in Chrome 133 after a successful origin trial.

For servers handling cross-site embedded content, implementing proper server-side logic to check for this header and respond appropriately is essential for maintaining secure and efficient cookie handling across origins.

Key points covered:

• Header fundamentals and purpose
• Three possible values: none, inactive, active
• Relationship to Storage Access API JavaScript methods
• Browser support and implementation
• Server-side handling and response headers

Understanding Storage Access in Cross-Site Contexts

Modern browsers partition cookies by site to prevent cross-site tracking. When a third-party site is embedded via iframe on a first-party page, it cannot access its cookies by default. The Storage Access API provides a mechanism for embedded content to request storage access permission from users.

Related concepts include storage area for managing browser storage and state partitioning for understanding how browsers isolate storage by site context.

Before HTTP Headers

Before HTTP headers support, storage access required JavaScript calls to document.requestStorageAccess(), which introduced latency and required JavaScript execution. The Sec-Fetch-Storage-Access header now allows browsers to communicate storage access status directly in HTTP requests, enabling more efficient server-initiated storage access flows.

When the Header Appears

The header applies only to:

• Cross-site requests with credentials mode set to "include"
• Requests where the requested resource has a potentially trustworthy origin

Same-site requests do not include this header since they cannot involve cross-site cookies.

Header Values and Their Meanings

none Value

When Sec-Fetch-Storage-Access: none, the context does not have the storage-access permission and cannot access unpartitioned cookies. This indicates the embedded content has never been granted storage access by the user or browser.

Servers receiving this value know that any cookies sent with the response will be partitioned and not accessible to the embedded content for cross-site identity purposes. This is the default state for most cross-site embedded content.

inactive Value

When Sec-Fetch-Storage-Access: inactive, the context has the storage-access permission but has not yet opted into using it for the current request context. The embedded content has been granted storage access previously but the permission has not been activated.

In this state, the embedded content cannot access unpartitioned cookies through normal means. However, the Origin header should also be set on requests with this value, allowing servers to identify the requesting origin and respond appropriately with the Activate-Storage-Access header to trigger permission activation.

active Value

When Sec-Fetch-Storage-Access: active, the context has unpartitioned cookie access. This means the embedded content can read and write cookies that are shared across sites, enabling cross-site identity and session persistence.

Requests with this value also include the Origin header, confirming the embedded site's identity. The cookies are sent with the request, allowing servers to authenticate the user and provide personalized content based on the cross-site identity.

The Activate-Storage-Access Response Header

The Sec-Fetch-Storage-Access request header works in conjunction with the Activate-Storage-Access response header. When a server receives a request with Sec-Fetch-Storage-Access: inactive, it can respond with Activate-Storage-Access to instruct the browser to activate the granted permission.

For a detailed explanation of how this response header works, see our guide on activating storage access.

Response Header Directives

The response header supports two directives:

load directive Tells the browser to grant the embedder access to unpartitioned cookies for the requested resource, without showing additional prompts to the user.

retry directive Instructs the browser to retry the request after activating the storage access permission.

Example Response Headers

Activate-Storage-Access: load
Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*

This two-header exchange enables a server-initiated storage access flow that is more efficient than the JavaScript-based approach, as it eliminates the need for round trips to execute requestStorageAccess() and wait for user permission grants.

Browser Support and Implementation

The Sec-Fetch-Storage-Access header was introduced in Chrome 133 following an origin trial that validated the feature's functionality and gathered developer feedback. Chrome's implementation follows the specification developed by the Privacy Community Group, making it the reference implementation for this feature.

Browser Considerations

• Other browsers may implement support based on their privacy policies and technical roadmaps
• Developers should check browser compatibility tables and implement progressive enhancement strategies
• The header is part of the broader Storage Access API, which includes JavaScript methods
• The HTTP headers complement rather than replace JavaScript APIs

JavaScript API Reference

The HTTP headers work alongside these JavaScript methods:

• document.hasStorageAccess() - Check if the context has storage access
• document.requestStorageAccess() - Request storage access permission
• document.requestStorageAccessFor() - Request storage access on behalf of another site

The HTTP header approach provides an alternative mechanism that can be more efficient in scenarios where server-side control is preferred.

Server-Side Implementation

Servers handling cross-site embedded content should implement logic to check for the Sec-Fetch-Storage-Access header and respond appropriately. Proper implementation requires understanding of web development best practices for handling HTTP headers and cross-origin requests.

Implementation Steps

1. Check for header presence - Detect Sec-Fetch-Storage-Access on incoming requests
2. Evaluate header value - Determine the storage access status:

• none: No permission granted, send partitioned cookies
• inactive: Permission exists but not activated, consider responding with Activate-Storage-Access
• active: Permission active, send unpartitioned cookies

3. Validate Origin header - Ensure requests come from expected embedded contexts
4. Send appropriate response - Use Activate-Storage-Access when activation is needed

Security Best Practices

• Validate the Origin header alongside Sec-Fetch-Storage-Access
• Use the allowed-origin parameter to restrict which origins can activate storage access
• Implement rate limiting to prevent abuse of storage access activation
• Log storage access attempts for security monitoring
• Consider user consent and privacy implications before activating storage access

Security Considerations

While the Sec-Fetch-Storage-Access header enables more efficient storage access, it maintains the same privacy protections as the JavaScript-based Storage Access API.

Built-in Protections

Forbidden Header Prefix The Sec- prefix on the header name indicates it is a forbidden request header that cannot be modified by JavaScript. This ensures the header value accurately reflects the browser's assessment rather than potentially manipulated values from embedded scripts.

Trustworthy Origin Requirement The header only appears on requests from potentially trustworthy origins, preventing malicious sites from exploiting the mechanism.

Server-Side Security Measures

• Validate the Origin header to ensure it matches expected embedded contexts
• Use allowed-origin parameter to restrict which origins can activate storage access
• Implement proper authentication and authorization checks even with active storage access
• Monitor and log storage access attempts for suspicious patterns
• Consider implementing content security policies that work alongside storage access

Privacy Compliance

The header supports privacy regulations by:

• Requiring user consent through the Storage Access API permission model
• Maintaining browser-based storage partitioning
• Allowing users to revoke storage access through browser settings

Relationship to Fetch Metadata

The Sec-Fetch-Storage-Access header is part of the broader fetch metadata family of headers, which provide servers with contextual information about requests.

Related Fetch Metadata Headers

Using Headers Together

Servers can use fetch metadata headers together to implement comprehensive security policies:

• CSRF Prevention: Check Sec-Fetch-Site to identify cross-site requests
• Resource Embedding Control: Use Sec-Fetch-Dest to validate request purposes
• Storage Access Management: Leverage Sec-Fetch-Storage-Access for cookie access decisions
• Request Validation: Combine multiple headers for robust request filtering

This multi-signal approach provides richer context for server-side security decisions while maintaining performance efficiency.

Sources

• MDN Web Docs - Sec-Fetch-Storage-Access Header
• Privacy Sandbox - Storage Access API HTTP Headers Support
• PrivacyCG Storage Access Headers Specification
• MDN Web Docs - Storage Access API