Why is a `Cross-Origin-Opener-Policy: unsafe-none` header unsafe?

user_1354350 0
Viewed 249

We recently upgraded a web application to Django 4 which now, by default, adds a

Cross-Origin-Opener-Policy: same-origin

header to http responses, which can cause window.opener to be null in the child window. This broke one of our pages where we had a child window (for SSO auth) sending a postMessage() back to the parent window when it was done doing its thing.

I know I can work around that by manually setting that header to unsafe-none, or structuring those pages differently, etc., but I'm curious what is potentially unsafe about the child window having access to window.opener?

Browsers keep window.opener pretty locked down, and there's not much that child windows can do with it other than calling postMessage() and a couple of other minor things.

Given that it is so locked down, what about it is unsafe? Can someone give an example of something damaging that a child window can do with window.opener that the browser will allow?

http-headers http
1 Answers

This is briefly noted on MDN on the page about noopener, which refers to this blog post.

Directly quoting this blog:

TL;DR If window.opener is set, a page can trigger a navigation in the opener regardless of security origin.

and

This is a relatively harmless example, but instead it could’ve redirected to a phishing page, designed to look like the real index.html, asking for login credentials. The user likely wouldn’t notice this, because the focus is on the malicious page in the new window while the redirect happens in the background.

You should redesign the flow of the login, so that it does not need the unsafe header. Especially if you accept arbitrary links from users.

user_25427270
Related