Secure popup interactions with restrict-properties

Get cross-origin isolation and cross-site leaks protection while interacting with popups.

Arthur Hemery

Maud Nalpas

A new value for Cross-Origin Opener Policy (COOP) is available: restrict-properties. It brings in security benefits and makes it easier to adopt cross-origin isolation while allowing your site to interact with third-party popups for payments, authentication, or other use cases.

To start experimenting with restrict-properties participate in the origin trial starting in Chrome 116.

Why use `restrict-properties`

restrict-properties has two main use cases:

Preventing cross-site leaks without breakage.
Making your site cross-origin isolated.

Prevent cross-site leaks without breakage

By default, any website can open your application in a popup and get a reference to it.

A malicious website can use this to their advantage to perform attacks such as cross-site leaks. To mitigate this risk, you can use the Cross-Origin-Opener-Policy (COOP) header.

Up until now, your options for Cross-Origin-Opener-Policy were limited. You could either:

Set same-origin, which blocks all cross-origin interactions with popups.
Set same-origin-allow-popups, which blocks all cross-origin interactions that open your site in a popup.
Set unsafe-none, which allows all cross-origin interactions with popups.

This made it impossible for websites that need to be opened in a popup and to interact with their opener to enforce COOP. This left key use cases like single sign-on and payments unprotected from cross-site leaks.

Cross-Origin-Opener-Policy: restrict-properties solves this.

With restrict-properties, properties that can be used for frame counting and other cross-site leaks attacks are not available—but basic communication between windows via postMessage and closed is allowed.

This improves a site's security while maintaining key use cases. For example:

If you provide a service in a popup, setting Cross-Origin-Opener-Policy: restrict-properties will protect yourself against a range of cross-site leaks attacks. You can still open all pages that you could previously open.
If you need to access a cross-origin popup, setting Cross-Origin-Opener-Policy: restrict-properties will similarly protect your site from iframe counting. You will be able to open the same set of popups that you can open today.
If both the opener and openee set the header, and the pages are cross-origin, it behaves similarly to one of them having set the header. If they are same-origin, full access is granted.

Make your site cross-origin isolated

Why we need cross-origin isolation

Some web APIs increase the risk of side-channel attacks like Spectre. To mitigate that risk, browsers offer an opt-in-based isolated environment called cross-origin isolation. With a cross-origin isolated state, the webpage can use privileged features including SharedArrayBuffer, performance.measureUserAgentSpecificMemory() and high-precision timers with better resolution, while isolating the origin from others unless they are opted in.

Up until now, to use these APIs, you had to set Cross-Origin-Opener-Policy: same-origin. However, this would break any cross-origin popup flow you might need, such as single sign-on and Payments.

Cross-Origin-Opener-Policy: restrict-properties can now be used instead of Cross-Origin-Opener-Policy: same-origin to enable cross-origin isolation. Instead of severing the opener relationship, it merely restricts it to the minimal communication subset of window.postMessage() and window.closed.

You will be able to enable cross-origin isolation with the following two headers:

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: require-corp

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: credentialless

Learn more about credentialless at Load cross-origin resources without CORP headers using COEP: credentialless.

Demo

Try various header options in this cross-origin isolation demo.

Experiment with the origin trial

To experiment with Cross-Origin-Opener-Policy: restrict-properties, opt into the origin trial.

Browser support

Cross-Origin-Opener-Policy: restrict-properties is currently only supported in Chrome. Other browsers are actively engaged in the discussion for standardization.

FAQ

My website needs to communicate with same-origin popups, should I use `COOP: restrict-properties` to enable cross-origin isolation?

Setting COOP: restrict-properties on both the popup and your main page will not cause restrictions. Setting it either only on the popup or only on the main page will prevent any access to properties other than postMessage and closed across the opener, even if they are same-origin.

Is the set of allowed properties fixed?

Based on the feedback so far, window.postMessage and window.closed are suspected to be enough for the majority of workflows, but we're still considering opening it to other properties. If you have a use case that cannot be solved using only postMessage and closed leave your feedback on the Intent to Experiment thread.