New sandbox allow-same-site-none-cookies value from Chrome 135

Natalia Markoborodova

From Chrome 135, you can use the new sandbox value: allow-same-site-none-cookies. When this policy is specified and third-party cookies are not available, the browser will only send SameSite=None cookies in HTTP requests originating from first-party sandboxed iframes.

What is a sandboxed iframe?

Sandboxed iframes are iframes with special restrictions. They are treated as having a null, opaque origin. By default, potentially harmful features like scripts, forms, and popups are not available within sandboxed iframes.

Use the sandbox attribute to specify which features a sandboxed iframe should have available. For example:

 <iframe sandbox="allow-scripts" src="example-sandboxed-frame.html"/>

Sandboxing is always a good idea, as it lets you to granularly select the permissions required for embedded content to load successfully, while limiting the scope of potential exploits.

Why do we need this new policy?

Before the introduction of allow-same-site-none-cookies, you could configure two cookie scenarios within a sandboxed iframe:

• Without the allow-same-origin token in the sandbox attribute, the iframe's origin is serialized as null, making all requests from the sandboxed page cross-site. In this case, only cookies with SameSite=None will be included in requests.
• With the allow-same-origin token in the sandbox attribute, requests are treated as originating from the iframe's real origin, allowing cookies with any SameSite value to be sent.

With third-party cookies blocked, a sandboxed iframe lacking allow-same-origin is unable to send any cookies unless you enable allow-same-site-none-cookies.

An iframe with allow-same-origin will still be able to include cookies in same-site requests, even when third-party cookies are blocked. However, the entire origin's cookie jar would be exposed to potentially malicious web activity.

With allow-same-site-none-cookies, an iframe can send SameSite=None cookies in HTTP requests, while potentially sensitive SameSite=Strict and SameSite=Lax cookies won't be included.

Practical example

Consider a site, practice-coding.example, that allows users to create and run custom coding projects and embed other users' code. To use the service, users must sign in, resulting in a SameSite=Strict session cookie being set.

Another user creates a project, practice-coding.example/cookie-theft, which other users can unknowingly embed as an iframe in their projects. If SameSite=Strict and SameSite=Lax cookies are exposed to the practice-coding.example/cookie-theft iframe, the malicious user could steal other users' session cookies.

In this scenario, the site owner may want to restrict access to potentially sensitive cookies. However, they may still want to allow SameSite=None cookies within sandboxed iframes. For example, practice-coding.example/coding-interview sandboxed iframe might require SameSite=None cookies to allow candidates to revisit their code. allow-same-site-none-cookies prevents exposing the entire cookie jar while selectively allowing the necessary SameSite=None cookies.

How do I allow only SameSite=None within first-party sandboxed frames?

To enable SameSite=None cookies in requests from first-party sandboxed pages, specify the allow-same-site-none-cookies token in the iframe tag. For example:

 <iframe sandbox="allow-same-site-none-cookies" src="example-sandboxed-page.html"/>

You can also set an allow-same-site-none-cookies policy with a Content-Security-Policy HTTP Header:

Content-Security-Policy: sandbox allow-same-site-none-cookies;

Try it yourself with our demo.

Engage and share feedback

File an issue to share feedback or report problems, or join the discussion on GitHub.