前端安全：不使用iframe能否限制第三方脚本的访问作用域？

不需要依赖iframe也可以实现前端代码的作用域限制和权限隔离，目前工业界已经有成熟的落地方案：

• Proxy代理全局对象沙箱
  这是当前微前端领域应用最广的实现思路，比如开源微前端框架qiankun的沙箱能力就是基于这个原理实现：给第三方脚本创建一个代理后的伪造window对象，脚本运行过程中所有对window的属性访问、赋值、枚举操作都会被Proxy拦截，你可以自定义可访问属性白名单，未授权的敏感属性（比如用户邮箱、业务埋点对象）直接返回undefined，同时拦截属性遍历操作，避免脚本通过枚举获取未授权信息。单页面多实例场景下还可以用增量快照沙箱实现不同脚本上下文的完全隔离，不会互相污染。
• with+闭包作用域拦截
  将第三方脚本的执行代码包裹在with语句中，with的入参为你自定义的作用域对象，再配合闭包手动覆盖顶层传入的window、document等全局变量，脚本运行时会优先读取自定义作用域内的属性，进一步补全Proxy可能存在的作用域逃逸漏洞。
• CSP规则兜底
  作为额外的防护层，你可以配置页面的Content Security Policy规则，禁止第三方脚本向未授权的域名发起请求，即使脚本意外获取到敏感信息也无法外传。

完全可行，WebAssembly本身的执行特性天然适合做更底层的权限隔离：

• WebAssembly默认无法直接访问JavaScript上下文的window、DOM等全局对象，所有和宿主环境的交互都必须通过实例化时主动传入的importObject导入函数完成，你可以完全控制暴露给WebAssembly的接口范围，未授权的全局属性它完全无法触达。
• WebAssembly的内存空间是独立分配的，你还可以限制它的最大内存占用、禁止它调用未授权的系统API，逃逸难度比JS层面的沙箱高很多。需要注意的是如果你给WebAssembly暴露了可以访问全局属性的JS函数，需要在这些函数中额外增加权限校验逻辑，避免被绕过。

需要注意的是，以上所有方案的安全等级都低于「不运行不可信代码」的保守方案，但是如果业务上必须集成第三方或跨团队代码，这些方案完全可以满足大多数场景的权限隔离需求。

内容的提问来源于stack exchange，提问作者David Min