Add new CSP sandbox directive to allow SameSite=None cookies on top-level frames

[DCtheTall]

Hey WebAppSec folks,

As you may already be aware, Chrome is shipping third-party cookie blocking by default in 2025.

One second order effect of this is any top-level document served with Content-Security-Policy: sandbox (e.g. untrusted user HTML content), which treats all subresource requests as cross-site, will have cookies blocked by default.

One unsatisfactory workaround for this is to include the allow-same-origin directive in the CSP sandbox header. This, however, exposes the hosting origin's entire first-party cookie jar (including SameSite=Lax/Strict cookies) to the sandboxed page, which is not feasible for some use cases from a security perspective.

In Chromium, I have landed a patch which allows users to opt-in to allowing top-level sandboxed pages to serve SameSite=None cookies only via a browser UI. However, I would like to gather feedback for an idea I had to provide an API-level solution for this as well.

One possible shape this API could take is a new directive for the CSP sandbox header:

Content-Security-Policy: sandbox allow-storage-access

This would allow top-level sandboxed pages to have access to their SameSite=None cookies by default when the page loads when third-party cookie blocking controls are enabled, without requiring the browser treat this as a first-party request with respect to SameSite.

This directive would have no effect on sandboxed frames that are not top-level in the page's frame tree, so there would be no privacy impact on users by introducing this.

I would like to hear feedback from the community on whether an API-level solution for this use case makes sense, and, if so, if the shape I am currently thinking of makes sense.

[annevk]

I don't understand why this would not work for A2 in a scenario where A1 embeds a same-site-but-sandboxed A2.

[johannhof]

CC @arturjanc @ddworken who motivated this idea, IIRC

I think this is a good idea, I do think we should bikeshed on the name a bit more though to avoid associating it with SAA and/or storage. To make another bad suggestion, allow-same-site-none-cookies?

I don't understand why this would not work for A2 in a scenario where A1 embeds a same-site-but-sandboxed A2.

I'm not sure off-hand either, @DCtheTall anything we're missing?

[DCtheTall]

I don't understand why this would not work for A2 in a scenario where A1 embeds a same-site-but-sandboxed A2.

I had originally thought to limit embeds from opting into this behavior, but now that you mention it, same-site embeds should be fine as well. Thanks for pointing that out!

[mikewest]

Pedantic nit: adding a new sandbox flag isn't a CSP feature request. It's probably best to move this conversation to HTML where you'd need to add the flag somewhere around https://html.spec.whatwg.org/multipage/browsers.html#sandboxing. Likewise, it sounds like the request would alter the definition of 6265bis' site for cookies in some way, though that's not entirely clear to me.

SameSite's relationship to sandbox is strange. I'm not at all convinced we made the right decision to use the creation URL rather than the origin for sandboxed documents, except insofar as it matched existing precedent/implementation. That said, don't we already handle this case in 6265bis's "site for cookies" definition by matching based on URL rather than origin when sandboxing flags are present? That is, in a case wherein example.com serves a sandboxed document at the top-level, we start with example.com in step 2, and we'll use example.com in step 4.1, making that the "site for cookies" for any outgoing request from that context.

I'm likely missing something about what the proposed flag would do differently in a post-3PCD world... Can you help me think through the scenarios you'd like to support?

[DCtheTall]

Likewise, it sounds like the request would alter the definition of 6265bis' site for cookies in some way, though that's not entirely clear to me.

@mikewest I am not sure I grok what you mean here. My original intention is not to change the SFC with this directive, but rather just allow the 1P site to receive its SameSite=None cookies despite privacy controls being enabled, since subresource requests in sandboxed frames are always considered cross-site even if the request URL is the same eTLD+1 as the document's URL. The request will still considered cross-site and only SameSite=None cookies can be included, so I do not think we are changing the SFC computation in any way. Or am I missing something?

[mikewest]

Hey @DCtheTall!

subresource requests in sandboxed frames are always considered cross-site even if the request URL is the same eTLD+1 as the document's URL

This isn't how the spec is written (see the distinction based on the sandboxed origin browsing context flag in the 6265bis steps linked above). Does it reflect browser's behavior?

I still feel like I'm misunderstanding something about the use case here, so I appreciate you bearing with me. :)

[DCtheTall]

Hey @mikewest

It seems there is a disagreement between the HTML spec, which instructs sandboxed frames to be treated as an opaque origin (hence all subresource requests are cross-site). This, to me, does not seem consistent with 6265bis.

Based on my local testing, Chrome, Firefox, and Safari do not include SameSite=Lax cookies in 1P subresource requests originating from a CSP: sandbox page (and only the former 2 block those cookies when 3PC controls are on FWICT).

Given all of this, I think the HTML spec is the correct behavior.