Get cross-origin isolation and cross-site leaks protection while interacting with popups.
A new value for
Cross-Origin Opener Policy (COOP)
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.
restrict-properties has two main use cases:
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
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
same-origin,which blocks all cross-origin interactions with popups.
same-origin-allow-popups, which blocks all cross-origin interactions that open your site in a popup.
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.
restrict-properties, properties that can be used for frame counting and
other cross-site leaks attacks are not available—but basic communication between
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-propertieswill 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-propertieswill 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
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
You will be able to enable cross-origin isolation with the following two headers:
Learn more about
Load cross-origin resources without CORP headers using
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
Cross-Origin-Opener-Policy: restrict-properties is currently only supported
in Chrome. Other browsers are
actively engaged in the discussion for standardization.
My website needs to communicate with same-origin popups, should I use
COOP: restrict-properties to enable cross-origin isolation?
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
across the opener, even if they are same-origin.
Is the set of allowed properties fixed?
Based on the feedback so far,
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
closed leave your feedback
on the Intent to Experiment thread.
- Making your website "cross-origin isolated" using COOP and COEP
- Why you need "cross-origin isolated" for powerful features
- A guide to enable cross-origin isolation
- SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome 92
- Load cross-origin resources without CORP headers using
COEP: credentialless- Chrome Developers
- Anonymous iframe origin trial: Easily embed iframes in COEP environments - Chrome Developers