为什么``交叉爆炸式'' - 不安全的标题不安全？
最近，我们将Web应用程序升级到Django 4，该应用程序现在默认情况下添加了
cross-origin-opener-policy：same-origin
标题到HTTP响应，这可能会导致window。 /code> be null在子窗口中。这打破了我们的一个页面之一，其中我们有一个子窗口（对于SSO auth），在完成操作后，将postmessage（）发送回父窗口。
我知道我可以通过手动将该标头设置为不安全的无，或以不同的方式构造这些页面来解决这个问题，但是我很好奇，对于儿童窗口而言，有什么可能不安全的，无法访问<<代码> window.opener ？
浏览器保留window.opener非常锁定，除了调用postmessage（）和其他几个次要的事情外，儿童窗口无法使用它。
鉴于它是如此锁定，那不安全呢？ 有人可以举个例子，说明子窗可以使用window.opener 浏览器允许 ？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在页面上的MDN上简要说明了，指的是此博客文章。
直接引用此博客：
和
您应该重新设计登录的流程，以便它不需要不安全的标头。特别是如果您接受用户的任意链接。
This is briefly noted on MDN on the page about noopener, which refers to this blog post.
Directly quoting this blog:
and
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.