允许用户提交代码在站点运行是否有风险？自定义作用域隔离方案是否可行？

• 最基础的this逃逸：非严格模式下，你写的普通立即执行函数内部this默认指向全局真实window，恶意代码只需一行const realWindow = this;即可完全绕开你传入的空对象限制，直接获取所有会话数据。
• 构造器逃逸：即便你开启严格模式避免this指向全局，恶意代码依然可以通过函数构造器执行动态代码跳脱参数限制，例如运行(function(){}).constructor('return window')()即可直接拿到真实全局对象，你重命名的window形参不会产生任何拦截效果。
• 原型链污染风险：你传入的空对象{}继承自全局Object.prototype，恶意代码修改该原型后会影响父页面所有对象的行为，属于严重的安全风险。
• 其他逃逸路径：动态脚本插入、eval执行、import加载外部脚本等常见操作你都没有做拦截，恶意代码可以通过多种方式拿到全局敏感数据。

方案1：无DOM操作需求优先用Web Worker #

Web Worker是浏览器原生提供的后台运行环境，天然和主线程上下文隔离，无法访问window、document、cookie等敏感资源，你需要给第三方代码传递的数据仅需通过postMessage主动传输即可，安全度极高，实现成本极低。

方案2：需要DOM操作优先用sandbox属性的iframe #

不需要配置独立子域名，给iframe添加 sandbox="allow-scripts"属性即可，默认完全和父页面跨源隔离，无法读取父页面的任何数据，每个第三方代码对应一个临时iframe，运行结束后直接销毁即可，性能开销远低于你自己实现沙箱。

方案3：必须自研沙箱的话优先使用原生API #

现代浏览器已经原生支持ShadowRealm API，专门用于隔离运行第三方JavaScript代码，天然隔离全局作用域，你可以自定义需要暴露给第三方代码的API，不需要自己处理各种边界逃逸问题。如果要兼容旧浏览器，也可以直接使用业内成熟的开源沙箱实现，不要手写极简IIFE做隔离，漏判的逃逸路径会非常多。

• 所有第三方代码运行前必须做静态检测，过滤敏感API调用特征，作为运行时隔离的补充防护
• 任何自定义暴露给第三方代码的API都要做严格的参数校验，避免恶意代码通过参数渗透获取上层真实对象
• 尽量限制第三方代码的运行时长，避免死循环等恶意代码占用用户设备资源

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