[This page] shows a security hole present in _many_ major websites, including (last I checked) Facebook (this is already known and not a new finding). This vulnerability is because window.opener.location is writable in child tabs/windows, even cross-origin; note that a read-only window.opener.location is not a security bug.
While a workaround exists, it is clumsy and very far from secure-by-default. Furthermore, I know of _no_ legitimate use cases for a child page to be able to force a navigation in the parent, and I would consider it horrible user experience.
I propose that window.opener.location be made read-only in pages that are from a different origin from the opening page.
My understanding is that many, many websites use this feature, and we cannot remove it as doing so would break the web. Any security here has to be opt-in, via the noopener rel, which is I assume what you are referring to as a clumsy workaround.
Others may know more, e.g. @mikewest.
@domenic Can you give an example of it being deliberately used to force navigation of another website, other than as an attack?
I understand that nulling out window.opener.location would be too much of a breaking change, and will drop that part.
I'm not proposing to drop window.opener (which I can see having legitimate uses). I am proposing to make window.opener.location read-only in the cross-origin case, on the grounds that no website ought to be able to force a navigation of a page that isn't from the same origin. That is enough to fix the security bug.
In fact, from what I can tell a writable window.owner.location in the cross-origin case is _always a security vulnerability_, barring trivial cases (ex. the writer is a trusted site).
window.location.href can't be read cross-origin, you can only set it. I doubt we can change that, though it would sure be nice.
@annevk Can you think of a case where being able to set it is useful?
It seems that this will fix bugs (security holes, no less) in far more websites that this breaks. What are the use cases for writing to it?
My understanding is that this is widely used for OAuth consent flows, where a popup is created to show the site from which permissions are accepted with the full https address bar. The user accepts the permission grant, and then window.opener.location is used to advance the original window to the next step in the flow with a reference to the newly created oauth token.
Thanks @hillbrad. I knew there was a common case but I couldn't recall what it was.
As such I think we need to close this issue, as it's not realistically going to be a change any browser can make.
Most helpful comment
My understanding is that this is widely used for OAuth consent flows, where a popup is created to show the site from which permissions are accepted with the full https address bar. The user accepts the permission grant, and then window.opener.location is used to advance the original window to the next step in the flow with a reference to the newly created oauth token.