JavaScript沙箱通过隔离执行环境防止第三方代码污染宿主，核心方案包括：eval()/new Function()因可访问全局对象存在逃逸风险；iframe提供独立文档和全局对象，实现强隔离，但有性能开销和跨域通信限制；Web Workers以线程级隔离保障安全且不阻塞UI，但无法直接操作DOM；而结合Proxy与with语句可构建轻量级软沙箱，通过拦截属性访问控制权限，适用于高性能、细粒度控制场景。
JavaScript的沙箱环境核心在于提供一个隔离的执行空间，让第三方代码在其中运行，而无法直接访问或修改宿主环境的全局对象、DOM或其他敏感资源。这就像给代码一个独立的“房间”，它可以在里面自由活动，但不能随意打开通往其他房间的门，更不能破坏房子结构。通过这种方式，我们能有效地避免恶意或有缺陷的第三方代码对应用造成全局污染或安全威胁。
解决方案
要实现JavaScript的沙箱环境，有多种策略，从轻量级到重量级，各有其适用场景。最常见的思路是利用语言特性或浏览器提供的隔离机制。
一种直接但相对不安全的做法是尝试通过
eval()或
new Function()来执行代码，并手动构建一个受限的执行上下文。但这往往治标不治本，因为这些方法本质上仍然在当前作用域链中执行，很容易通过
window、
this等关键词“逃逸”到全局。我个人觉得，如果只是想简单地隔离一些纯计算逻辑，这种方式勉强可用，但涉及到任何外部交互或不确定代码来源时，风险就太大了。
更可靠的隔离手段则依赖于浏览器提供的更强的隔离机制：
iframe和
Web Workers。
iframe提供了一个独立的文档环境和全局对象，几乎是物理级别的隔离；而
Web Workers则将代码运行在完全独立的线程中，拥有独立的全局上下文，且无法直接访问DOM，这在性能和安全性上都有显著优势。
立即学习“Java免费学习笔记（深入）”；
此外，对于需要在同一线程内进行“软沙箱”处理的场景，可以利用ES6的
Proxy对象，结合
with语句（尽管
with在严格模式下被禁用且通常不推荐，但在特定沙箱构建中，它能提供一个临时的作用域链插入点）来拦截和控制对全局对象的访问。这更像是一种“虚拟”的沙箱，通过拦截属性读写来实现控制，而非真正的内存隔离。
为什么直接使用eval()或new Function()存在安全风险？
当我们在JavaScript中使用
eval()或
new Function()来执行第三方代码时，即使我们尝试通过闭包或参数传递来限制其访问范围，它们也并非完全安全。在我看来，这两种方式就像是给了一个带有后门的安全屋，虽然表面上看起来隔离了，但只要代码足够“聪明”，总能找到办法溜出去。
eval()的风险尤其大，因为它会在当前的词法作用域中执行代码。这意味着，如果你的代码中定义了敏感变量，
eval()中的恶意代码可以直接访问并修改它们。比如，你有一个
let secretToken = '...'，
eval('console.log(secretToken)')就能轻易打印出来。更糟糕的是，它能直接访问和修改全局的window对象，比如
eval('window.location.href = "malicious.com"')，这简直是灾难。
new Function()相对来说要好一点，因为它创建的函数总是运行在全局作用域中，而不是其被创建时的局部作用域。但它依然能访问全局对象，例如
new Function('console.log(window.document)')()就能获取到文档对象。虽然它不能直接访问其外部闭包中的局部变量，但通过this上下文或全局对象，它依然可以对宿主环境造成污染。例如，如果你的全局对象上挂载了某些敏感方法，
new Function()执行的代码就能直接调用。
所以，如果第三方代码的来源不可信，或者你对代码的内容没有完全的掌控，直接使用
eval()或
new Function()来构建沙箱，其安全防护能力是非常脆弱的。我们需要的，是更深层次的隔离。
iframe和Web Workers在实现沙箱环境时有哪些核心优势与局限？
iframe和
Web Workers是实现JavaScript强隔离沙箱环境的两大利器，它们各有千秋，也都有各自的“脾气”。
iframe的优势在于它提供了真正的运行时隔离。每个
iframe都有自己独立的全局对象（
window）、独立的文档（
document）和独立的JavaScript执行环境。这意味着，在一个
iframe中运行的代码，即使它尝试修改
window.location或者覆盖
Array.prototype，也只会影响到它自己的
iframe内部，而不会波及到父页面或其他
iframe。这种隔离性使得
iframe成为执行不可信代码的理想选择，尤其是在需要模拟浏览器环境（如渲染HTML、操作DOM）时。我个人在做一些富文本编辑器或第三方插件预览功能时，经常会用到
iframe来确保安全。
然而，
iframe也有其局限性。首先是性能开销。创建一个
iframe需要浏览器加载并初始化一个新的文档环境，这会消耗一定的内存和CPU资源。其次是跨域通信的复杂性。如果
iframe和父页面不是同源的，它们之间的通信只能通过
postMessageAPI进行，而且需要非常小心地验证消息来源和内容，以防范XSS攻击。此外，
iframe虽然隔离了JavaScript环境，但它仍然共享主线程的事件循环，如果
iframe内的代码执行了长时间的同步操作，仍然可能阻塞主页面的UI。
Web Workers则提供了线程级别的隔离，这是它最显著的优势。它将JavaScript代码运行在主线程之外的另一个独立线程中，这意味着即使Worker内部有复杂的计算或死循环，也不会阻塞主页面的UI响应。Worker拥有独立的全局对象（
self），且无法直接访问DOM，这进一步增强了其隔离性。对于那些计算密集型任务，比如图像处理、数据加密、大型数组排序等，
Web Workers是完美的选择。
但
Web Workers的局限性也同样明显。最主要的一点是它无法直接访问DOM。这意味着你不能在Worker内部直接操作页面元素。所有与主线程的通信都必须通过
postMessage和消息事件监听器进行，并且传递的数据需要是可序列化的。这引入了数据序列化/反序列化的开销，对于大量或复杂的数据传输，可能会成为性能瓶颈。另外，Worker的调试也相对复杂一些，不像直接在主线程中那样直观。所以，如果你需要第三方代码操作DOM，
Web Workers就不太合适了。
如何利用Proxy和with语句构建一个轻量级的JavaScript沙箱？
利用
Proxy和
with语句来构建沙箱，这是一种在同一线程内实现“软沙箱”的策略，它不像
iframe或
Web Workers那样提供物理级别的隔离，但可以有效地控制第三方代码对宿主环境的访问。我通常会在一些对性能要求高、且第三方代码相对可信（但仍需限制其行为）的场景下考虑这种方案。
首先，我们得聊聊
with语句。
with语句在严格模式下是被禁止的，并且由于其对作用域链的修改，常常导致代码难以理解和优化，所以通常不建议使用。但在沙箱场景中，它能提供一个临时的作用域链插入点。例如：
function createSandboxedFunction(code, context) {
// context 是我们希望沙箱代码能够访问的属性集合
// 例如 { console: console, fetch: fetch }
const wrappedCode = `with (sandboxContext) { ${code} }`;
// 注意：这里的 new Function 会在全局作用域创建函数
// 但 with 语句会先查找 sandboxContext，然后才是全局
return new Function('sandboxContext', wrappedCode);
}
const sandboxContext = {
// 只暴露我们希望第三方代码访问的API
log: console.log,
add: (a, b) => a + b
};
try {
const sandboxedFunc = createSandboxedFunction('log("Hello from sandbox!"); console.log(add(1, 2)); alert("Trying to alert!");', sandboxContext);
sandboxedFunc(sandboxContext);
} catch (e) {
console.error("Sandbox execution error:", e);
}
// 这里的 alert 不会执行，因为 sandboxContext 中没有 alert然而，仅仅依靠
with语句是远远不够的，因为沙箱代码仍然可以通过
window或
globalThis直接访问到全局对象。这时，
Proxy就派上用场了。
Proxy允许我们拦截对一个对象的各种操作，比如属性的读取（
get）、写入（
set）、判断是否存在（
has）等。我们可以创建一个“假”的全局对象，然后用
Proxy包装它，拦截所有对全局属性的访问。
function createSecureSandbox(code, allowedGlobals = {}) {
const sandboxGlobal = { ...allowedGlobals }; // 初始允许的全局变量
// 创建一个Proxy来拦截对sandboxGlobal的访问
const proxyHandler = {
has(target, key) {
// 阻止访问一些敏感的全局属性
if (['window', 'document', 'location', 'eval', 'Function', 'alert', 'fetch', 'XMLHttpRequest'].includes(key)) {
console.warn(`Attempted to access restricted global: ${key}`);
return false; // 假装这些属性不存在
}
return key in target || key in globalThis; // 优先从沙箱上下文查找，然后是真实的全局
},
get(target, key, receiver) {
if (['window', 'document', 'location', 'eval', 'Function', 'alert', 'fetch', 'XMLHttpRequest'].includes(key)) {
console.warn(`Attempted to read restricted global: ${key}`);
return undefined; // 返回 undefined 或抛出错误
}
// 如果沙箱上下文有，就返回沙箱的
if (key in target) {
return Reflect.get(target, key, receiver);
}
// 否则，从真实的全局对象中获取（如果允许）
// 这里可以根据需要，进一步限制对globalThis的访问
return Reflect.get(globalThis, key, receiver);
},
set(target, key, value, receiver) {
if (['window', 'document', 'location'].includes(key)) {
console.warn(`Attempted to write to restricted global: ${key}`);
return false; // 阻止写入敏感全局属性
}
// 允许写入到沙箱上下文
return Reflect.set(target, key, value, receiver);
}
};
const sandboxedContext = new Proxy(sandboxGlobal, proxyHandler);
// 将代码包装在一个立即执行函数中，并将沙箱上下文作为参数传入
// 这样，代码中的this和全局访问都将被限制在sandboxedContext内
const wrappedCode = `
(function(global) {
with (global) {
${code}
}
})(sandboxedContext);
`;
// 使用new Function来执行包装后的代码
// 注意：这里的new Function仍然在全局作用域创建，但内部通过with和Proxy进行了限制
return new Function('sandboxedContext', wrappedCode);
}
// 示例用法
const userCode = `
console.log('Hello from sandboxed code!');
var myVar = 'local';
console.log('myVar:', myVar);
// 尝试访问被限制的全局对象
try {
console.log('window:', window);
} catch (e) {
console.error('Error accessing window:', e.message);
}
// 尝试修改全局对象
document.body.style.backgroundColor = 'red';
// 尝试访问允许的全局
console.log('Allowed value:', allowedValue);
`;
const allowedAPIs = {
console: console, // 允许访问宿主的console
allowedValue: 123 // 自定义一个允许访问的全局变量
};
try {
const executeSandbox = createSecureSandbox(userCode, allowedAPIs);
executeSandbox(allowedAPIs); // 传入初始允许的全局变量
} catch (e) {
console.error('Execution failed:', e);
}这个
Proxy和
with结合的方案，通过
Proxy拦截了对
sandboxedContext的属性访问，使得沙箱代码无法直接获取到真实的
window、
document等敏感对象。同时，
with语句确保了在沙箱代码内部，未声明的变量会首先在
sandboxedContext中查找，然后才向上查找作用域链。这提供了一个相对轻量级但有效的隔离层。当然，这种方式的安全性高度依赖于
Proxy拦截逻辑的完善程度，需要非常仔细地设计
proxyHandler来覆盖所有可能的“逃逸”路径。它是一个权衡，在性能和安全性之间找到了一个平衡点，尤其适合那些对性能敏感、且需要对第三方脚本进行细粒度控制的场景。
