iframe and postMessage

[baymaxcoin]

1. iframe 基础

HTML 内联框架元素 (<iframe>) 表示嵌套的browsing context。它能够将另一个 HTML 页面嵌入到当前页面中。

2. 安全 🔐

2.1 对于使用iframe的页面

iframe属性

iframe标签有些属性可以限制被嵌入页面的能力：

1. 沙箱属性 sandbox
2. 权限控制 allow

2.2 对于被嵌入的页面

如何检测自己被嵌套了？

方法一：比较 window.self 与 window.top

如果当前页面是最顶层的窗口，那么window.self 和 window.top 指向同一个对象；反之，则说明页面被嵌套了。

if (window.self !== window.parent) {
    console.log('当前页面被嵌套在 iframe 中');
    // 在这里可以执行跳出嵌套等操作
} else {
    console.log('当前页面是顶级窗口，未被嵌套');
}

这个判断逻辑也可以写成 window.top !== window.self或 window !== window.top。

扩展：window.opener / window.parent / window.top 的区别？

1. window.opener refers to the window that called window.open( ... ) to open the window from which it's called
2. window.parent refers to the parent of a window in a <frame> or <iframe>
3. window.top refers to the top-most window from a window nested in one or more layers of <iframe> sub-windows

如何禁止被嵌套？

1. X-Frame-Options 响应头

X-Frame-Options 标头已被 Content Security Policy Level 2 中的 frame-ancestors 指令取代。

https://caniuse.com/?search=X-Frame-Options

2. Content-Security-Policy 响应头

frame-ancestors 指令允许指定哪些父级 URL 可以将当前资源嵌入frame中。通过使用 frame-ancestors 这个 CSP 指令，我们可以阻止或允许页面被放置在frame 或 iframe内。

2.3 安全使用window.postMessage()

当父窗口需要与其iFrame通信时（反之亦然），直接的JavaScript访问通常会被同源策略阻止。跨源通信的推荐安全方法是window.postMessage()。但是要安全的使用window.postMessage()：

• 始终验证发送者的来源：接收消息时，务必检查event.origin属性，以确保消息来自预期的来源。

• 指定目标来源：发送消息时，提供确切的目标来源（例如，iframeWindow.postMessage('hello', 'https://expected-origin.com');），而不是*。使用*意味着任何窗口都可能接收您的消息，这是一种安全风险。

// 正确：只发送给可信的源
iframe.contentWindow.postMessage('user data', 'https://trusted-domain.com');

• 净化接收到的数据：将通过postMessage()接收到的任何数据视为不可信输入，并在使用前对其进行净化，以防止XSS。

有了window具柄了为啥还需要targetOrigin参数?

调用postMessgeAPI时，获取到的 otherWindow 引用，比如 iframe.contentWindow 或 window.opener，本质上是一个“指针”。它指向一个窗口对象，但无法保证这个窗口当前加载的页面是预期的（比如用户在iframe里跳转了其他网站）。这个时候就需求postMessage 的 targetOrigin 参数。

targetOrigin 如何提供保护？

targetOrigin 参数要求你明确指定一个源（Origin，包括协议、域名和端口），浏览器在发送消息时会进行校验。

• 校验机制：只有在目标窗口的源与 targetOrigin 完全匹配时，消息才会被发送。如果不匹配，消息会被浏览器直接丢弃，不会发出。
• 精准投递：这个机制确保了消息只能被发送到你指定的、可信的源，而不是任何碰巧占用该窗口引用的网站。

参考

1. 由postMessage跨域解决方案引发的双核浏览器兼容性问题的调查与解决方案
2. iFrame嵌入安全：Web开发人员的最佳实践
3. MDN Content-Security-Policy: frame-ancestors directive
4. Google 在您的网站上安全地嵌入内容

[baymaxcoin]

和动态加载的iframe进行通讯

背景：

动态加载iframe后向iframe页面通过postMessage发消息。
疑问🤔：iframe的load事件触发时iframe页面的JS执行完成了吗？

了解load事件

load 事件在整个页面及所有依赖资源如样式表和图片都已完成加载时触发。

load 和 DOMContentLoaded的区别

MDN 上已经有清晰的描述：

1. DOMContentLoaded: 当 HTML 文档完全解析，且所有延迟脚本（<script defer src="…"> 和 <script type="module">）下载和执行完毕后，会触发 DOMContentLoaded 事件。它不会等待图片、子框架和异步脚本等其他内容完成加载。
2. load 事件在整个页面及所有依赖资源如样式表和图片都已完成加载时触发。它与 DOMContentLoaded 不同，后者只要页面 DOM 加载完成就触发，无需等待依赖资源的加载。

疑问2: load事件触发时，iframe页面的useEffect执行了吗 ?

实际开发过程中发现绝大多数都是iframe的load事件早于useEffect执行。但是偶尔出现useEffect早于iframe的load事件执行。
理论上有先后顺序保证吗？
先说结论：他俩是两个独立且并行的过程。
JS加载执行完成才会进入React的渲染逻辑，而JS资源只是影响load事件的资源之一。它们之间没有固定的先后顺序。

这种情况下如果保证iframe页面收到postMessage消息呢？

1. 父页面轮训？
2. iframe页面主动发起“握手”，即在其useEffect里监听onMessage后主动向父window发送个“I am Ready“的消息。