Cross-Origin-Opener-Policy: change defaults to not expose the opener

[empijei]

When Cross-Origin-Opener-Policy: * unsafe-allow-outgoing is specified the current context can open windows cross-origin and they will get a reference to the opener.

This behavior can be avoided by setting rel=noopener in all a tags and have the window.open noopener feature set to "yes" or manually assigning null the opener property after opening.

This makes every call to window.open and every a tag a potential vulnerability, making it much easier for developers to get this wrong.

My proposal is to change default behaviors and automatically set "noopener" to all links and window.open calls, requiring developers to specify a rel="opener" on a tags and opener=yes on window.open features.

Note: the "opener" value was already proposed to address similar unsafe defaults on _blank targets.

@annevk raised a concern about this proposal because it could make it harder to deploy COOP, I wonder how many applications that are interested in COOP are also willing to give away window references. I'll update this bug as soon as I have data about it.

/cc @arturjanc @mikewest

[annevk]

Note that we could consider doing this even if unsafe-allow-outgoing was not specified, meaning it'd be required for same-origin/same-site as well (since the default is noopener), but that has the same concerns.

Another problem might be deciding what to do here for the reporting mode (assuming we can figure out something agreeable there).

[arturjanc]

I'd be a little wary of requiring developers to make application changes in this case; it would mean that even a less strict version of COOP with unsafe-allow-outgoing would be gated on refactoring markup and scripts to use rel="opener" for popups. If this is controlled by a library (e.g. a "Login with X" OAuth flow) it would prevent the site from using COOP until its dependencies start setting this attribute.

unsafe-allow-outgoing is meant as an escape hatch for sites which open cross-site popups and need to interact with them. It's a compromise which accepts the possibility that some popups (which are ultimately under the control of the site) will be opened in the existing browsing context group, but allows sites to adopt COOP to protect themselves from interactions from untrusted openers, which is a more likely attack scenario and common vector for cross-site leak bugs.

It seems okay to expect developers to explicitly set rel="noopener" if they open popups to untrusted user-controlled destinations and their COOP has unsafe-allow-outgoing. For rel="opener", I'd see it as a more promising fit for poking holes in the stricter COOP variant: e.g. if you have Cross-Origin-Opener-Policy: same-origin a developer potentially could add rel=opener to some trusted popups as a more granular way to pull them into the existing browsing context group. Doing this at the level of individual links rather than the entire document could reduce the need to use unsafe-allow-outgoing in the first place.

[annevk]

I don't think the latter can ever be permitted as part of the threat model here is that the site specifying Cross-Origin-Opener-Policy can be the attacker, so letting them opt out of self-imposed restrictions through markup alone would not be good.

[arturjanc]

Are you talking about the restrictive "CORP-P" case where we'd use COOP as a way to ensure that all your cross-origin links would open in a different browsing context group?

If so, then I see your point, but since we'd have to disallow or ignore unsafe-allow-outgoing on such documents, we could possibly similarly ignore rel="opener" if it allowed the same behavior. (This may be less elegant, though, because it would be enforced at a different time, upon the page performing a navigation or opening a popup.)

[annevk]

Hmm, unsafe-allow-outgoing in combination with CORP-P/TBD is fine, I think. It does not seem fine however for markup to override header decisions, assuming the suggestion is that rel=opener could override a COOP header without unsafe-allow-outgoing.

[arturjanc]

The main danger I see is that developers could unwittingly add rel="opener" to their links on pages with a strict COOP, so this is a concern. OTOH it would also have the positive effect of not requiring a document-wide relaxation of COOP if you have one cross-site popup, which could potentially outweigh this risk.

One thing I'd prefer to avoid is requiring developers who specify unsafe-allow-outgoing to additionally need to refactor their markup / scripts to add rel="opener" because that would increase the amount of work required to adopt COOP.

If you don't like rel="opener" poking holes in COOP then maybe we can stick to the current model?

[annevk]

Yeah, I think the current model is best given the constraints imposed by "legacy" adoption. Perhaps flipping the default on openers could be yet another toggle.

[annevk]

Closing per the above discussion. If an additional toggle would be worth having please do say so, though this might be good as a document policy (per the ongoing Feature Policy revamp) instead.