#沙箱机制与 iframe

#1. 为什么需要沙箱？

现代复杂 Web 系统常常需要引入第三方的插件、广告或其他合作方的模块代码。如果直接在当前页面引入这些第三方的 <script>，它们就自动具备了当前全局环境的所有执行权限。一旦存在恶意代码逻辑，它们可以访问全局的变量、抓取本地存储里的凭据、甚至接管并破坏整体 DOM 结构。

因此，为了保证主应用运行的安全，需要搭建一个限制外来代码执行能力的隔离运行环境，即沙箱机制。

#2. 原生的沙箱：iframe

<iframe> 是使用最为成熟广泛的原生隔离方案。嵌入在 iframe 中的应用天然处于一个与父级容器文档完全独立的上下文和内存区域中，无论内部出现多严重的脚本错误，都不会直接阻塞或导致外侧的主应用崩溃。

#3. sandbox 属性的限制配置

虽然具备了执行基础的物理隔离，但第三方仍然可以在其中通过改变外部指针实现跳转重定向，或弹出异常窗口。为了干预这些违规操作风险，HTML5 引入了功能限制控制的 sandbox 指令属性。

直接配置 <iframe sandbox src="..."> 时，该 iframe 默认的多数执行权限会被剥夺：不能执行 JS、不能提交表单、不能创建关联弹出处理窗口、强行被视为执行跨域处理。需要开发者针对性地进行白名单精细化授权：

<iframe 
  src="http://third-party.com"
  sandbox="allow-scripts allow-same-origin"
></iframe>

#安全陷阱

如果在包含同源内容的外部 iframe 目标上，粗心地同时赋予了 allow-scripts 和 allow-same-origin 这个组合策略机制。 该同页便可利用自身具有的脚本直接执行权限，发起移除或抹除自身配置指令标签的解除步骤，或者尝试通过跨层上级引用调起访问且篡改外置主窗体信息的关联获取行为操作，从而使得预先声明的拦截隔离控制屏障形同虚设失效。

#4. 微前端架构中的沙箱应用

由于 iframe 原生自带独立路由体系、布局显示边界裁断、底层资源隔离化等多种特性，新生代前端中涉及多架构联合渲染体系的前端框架大多转为运用 JS 代码级沙箱建立虚拟安全边界控制。

实现原理的底层运用多包含采取通过定义 ES6 Proxy 等语法规则。向每个独立执行单元分派一个预制拦截伪装全局配置对象。控制子处理块发生试图改变影响跨系统全局设定的交互，拦截保存内部影响仅归属到局部的自持状态当中记录和维护，维持主要框架底座的无痕不受影响状态。