CSPv3指定新的disown-opener政策：
disown-opener指令确保导航到资源时disown its opener。
链接的WHATWG规范也不是非常有用：
获取时，Window对象上的opener IDL属性必须返回创建当前浏览上下文的浏览上下文的WindowProxy对象（其开启者浏览上下文），如果有的话，它是否仍然可用，如果当前浏览上下文没有否认其开启者;否则，它必须返回null。在设置时，如果新值为null，则当前浏览上下文必须拒绝其开启者;如果新值是其他任何值，那么用户代理必须调用Window对象的[[DefineOwnProperty]]内部方法，传递属性名称＆＃34; opener＆＃34;作为属性键，属性描述符{[[Value]]：value，[[Writable]]：true，[[Enumerable]]：true，[[Configurable]]：true}作为属性描述符，其中value是新的价值。
答案 0 :(得分：7)
它会导致window.opener在任何新窗口或标签上设置为null，这些新窗口或标签会从包含disown-opener指令的CSP标头提供的任何文档中导航到。
用例类似于rel=noopener的用例。
这两种攻击都是为了防止这种情况造成的，例如当你的文档A中有链接到文档B（可能是另一个来源）时，文档B中的任何脚本都可以通过值{ {1}}访问和控制文档A中的窗口对象。
因此，文档B的脚本可以将窗口文档A的window.opener值更改为文档C的URL，以便该窗口从文档A导航到该URL。
如果文档C的设计看起来与文档A完全相同，包括欺骗性登录表单，则可以用来欺骗用户和网络钓鱼用户凭据。
Mathias Bynens在About rel=noopener: What problems does it solve?中详细介绍了这个问题。
在导航的文档上设置window.opener.location到window.opener以防止出现此问题。
如果没有null的用例，文档A首先需要打开一个新的标签/窗口到它控制的文档/位置，然后使用脚本将disown-opener设置为{{1然后在该选项卡/窗口中的文档处将脚本导航到文档B。
更新1：我已raised a PR against the HTML spec为此规范添加信息性说明。
更新2： patch from the PR above已合并到HTML规范中，因此now has this note：
如果浏览上下文是 disowned ，则其
window.opener属性为null。这可以防止浏览上下文中的脚本更改其开启者浏览上下文的null对象（即创建浏览上下文的window.opener对象）的任何属性。否则，如果浏览上下文不是 disowned ，则该浏览上下文中的脚本可以使用
Window更改其开启者浏览上下文的属性Window宾语。例如，在浏览上下文中运行的脚本可以更改window.opener的值，从而导致开启者浏览上下文导航到完全不同的文档。