我正在我的应用程序中动态创建一个 iframe，结果如下所示：
<iframe src="blob:http%3A//localhost%3A9292/0194dfed-6255-4029-a767-c60156f3d359"
scrolling="no" sandbox="allow-scripts allow-popups allow-same-origin"
name="sandbox" style="width: 100%; height: 100%; border: 0px;"></iframe>
拥有这样的沙盒配置是否安全(特别是允许将 iframe 内容视为来自同一来源(？
正如 Namey 所评论的那样，allow-same-origin 不允许将 iframe 视为与父级来自同一源的，并且可以安全使用(除非父级和 iframe 共享相同的源，参见：MDN 上的警告(。
如 https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/#granular-control-over-capabilities 所述：
框架文档被加载到唯一的原点，这意味着所有同源检查都将失败;唯一原点与其他原点不匹配，甚至它们自己也不匹配。除其他影响外，这意味着文档无法访问存储在任何来源的 cookie 或任何其他存储机制(DOM 存储、索引数据库等(中的数据。
你在 IFrame 上设置了以下具有 Blob URL/Object-URL 的设置。
-
allow-scripts -
allow-popups -
allow-same-origin
我假设 IFrame 的内容是从用户/不受控制的输入生成的，并且可能包含 HTML 和/或脚本。
首先，让我们一一介绍这些。
允许脚本
这允许 IFrame 中的 JavaScript 代码运行。这可能很危险，具体取决于设置的其他值。
仅使用allow-scripts，任何脚本都可以
- 发出 AJAX 请求，例如
fetch，尽管任何回应都无法被IFrame阅读。例如，向恶意用户 Web 应用发送跨站点请求伪造 (CSRF( 攻击或"呼叫总部"。请注意，与流行的看法相反，AJAX可以发送到任何源(Cross-origin writes are typically allowed(，同源策略仅阻止读取响应，而不是写入。此外，它只能发送与外部托管网页相同的CSRF攻击 - 如果没有allow-same-origin，它将无法从父级读取令牌的值。 - 使用
document.location自动将用户导航离页面 - 请注意，这是在 IFrame 内，而不是在 IFrame 之外。 - 托管表单(例如，要求输入用户名和密码(，以从用户那里捕获凭据，如果攻击者模仿您外部的样式，则特别有效。请注意，这不需要
allow-forms因为攻击者可以简单地使用 JavaScript 将数据发布到他们自己的站点。
允许弹出窗口
允许从链接或JavaScript打开新窗口/选项卡。后者还需要设置allow-scripts。
允许同源
如果文档的原点兼容，这允许使用相同的来源。请注意，这不会覆盖任何默认来源 - 也就是说，攻击者不能在 IFrame 中托管 Twitter.com 并使用它来访问页面中受害者的 cookie 或 CSRF 令牌，也不能简单地加载 Twitter.com 并假装内容是从与父源相同的来源生成的。
对于 Blob URL/对象 URL，这会将 IFrame 设置为与其父级具有相同的源，从而允许读取和操作你创建的 IFrame 中的对象。
无需设置allow-scripts，所有这些功能本身就是允许您的外部 IFrame 操作和读取对象，但是，allow-scripts这允许 IFrame 操作和读取父级中的对象，即您的页面，这是不安全的。
因此，由于allow-scripts和allow-same-origin，此设置会在应用程序中引入跨站点脚本 (XSS( 缺陷。最好考虑不需要allow-same-origin的此问题的替代解决方案。我不确定您希望从您的问题中使用此值实现什么，但在大多数情况下可以找到替代方案。
allow-same-origin不安全。这将使iframe有可能访问父数据(例如本地存储(
此外，allow-same-origin将允许 iframe 向父级的 API 发出 ajax 请求，这也可能是有害的。
但是，要使iframe访问父级的数据，它还需要执行脚本，因此没有allow-scripts allow-same-origin是无害的
至于allow-popups，iframe可以做的不安全的事情并不多，除了它可以打开其他网址的事实