在线运行JavaScript代码时的沙箱限制与跨域问题

一、为什么在线运行代码必须处于严格沙箱中？

任何允许用户输入并即时执行任意 JavaScript 代码的在线平台，其本质都是在浏览器主线程中运行一段完全未知的不可信代码。如果直接在宿主网页的主执行上下文中调用 eval() 或动态插入 <script> 标签，该代码将获得宿主页面的全部特权：读取宿主域下存储的用户登录凭据（Cookie、Token、IndexedDB）、操纵宿主页面的 DOM 节点、甚至伪造用户操作向后台下发恶意请求。

为了切断不可信脚本对宿主系统及其他访客的威胁，主流平台都会把用户代码安置在受限的 <iframe sandbox="..."> 环境中执行。沙箱（Sandbox）通过浏览器原生的安全边界，将代码的执行权限压制在极小的受控区域内。

图 1: 在线 JavaScript 代码执行环境的分层隔离架构（宿主环境、沙箱环境与外部网络隔离边界）

1. 沙箱核心标记与最小权限控制

现代浏览器规范（HTML5 规范）为 <iframe> 提供了强大的 sandbox 属性。只要在标签上标注了该属性，默认情况下该内嵌页面将受到全部限制：禁止运行脚本、禁止表单提交、禁止弹窗、禁止同源访问等。在线代码编辑器通常会按需开启指定能力：

2. 本地存储受限与 DOM 访问阻断

当 iframe 配置了 sandbox="allow-scripts" 但没有配置 allow-same-origin 时，规范规定该 iframe 的 Origin 将被赋予一个全新的、唯一的不透明源（Opaque Origin），在 JavaScript 中读取 window.origin 的返回值是纯字符串 "null"。

由于来源是不透明的 null，所有依赖同源域名的浏览器存储与通信接口都会立刻失效：

• 本地存储被禁：尝试访问 window.localStorage 或 window.sessionStorage 会立即抛出异常。
  控制台报错示例Uncaught DOMException

  Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.

• 父窗口 DOM 穿透受阻：尝试访问 window.parent.document 或 window.top 会触发跨域安全异常：
  控制台报错示例SecurityError

  Uncaught SecurityError: Blocked a frame with origin "null" from accessing a cross-origin frame.

二、沙箱中的跨域难题：为什么直接发起网络请求总是失败？

许多初学者在在线演练场中调试网络通信代码时，发现调用 fetch('https://api.example.com/data') 几乎总是直接报错进 catch。这涉及浏览器同源策略（SOP）与跨域资源共享（CORS）在沙箱特殊环境下的联动反应。

图 3: 沙箱环境发起跨域请求的时序流转与浏览器拦截机制

1. 不透明源带来的 CORS 拦截

当沙箱中的 JavaScript 发起网络请求时，浏览器内核的网络层会自动提取当前文档的 Origin 并附加到 HTTP 请求头中：

GET /api/users HTTP/1.1
Host: api.example.com
Origin: null
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site

注意请求头中的 Origin: null。当该请求到达外部目标服务器后，目标服务器通常有以下几种响应行为：

1. 未配置 CORS 响应头：服务器只返回普通数据，未包含 Access-Control-Allow-Origin。浏览器网络栈对比发现当前源为 null，直接判定跨域失败，将响应数据丢弃，并向上层 JavaScript 抛出 TypeError: Failed to fetch。
2. 配置了域名白名单：服务器返回 Access-Control-Allow-Origin: https://myapp.com。浏览器校验发现 "https://myapp.com" !== "null"，同样立刻阻断。
3. 服务端配置了通配符：服务器返回 Access-Control-Allow-Origin: *。在简单请求（Simple Request，如无自定义 Header 的 GET 请求）且不带凭据时，浏览器允许读取响应；但一旦包含自定义 Header（例如 Authorization）触发预检请求（OPTIONS），或者代码配置了 credentials: 'include'，浏览器依然会直接拦截并抛错。

2. 混合内容拦截（Mixed Content）

另一个极为普遍但容易被忽视的原因是混合内容。当今所有在线代码编辑平台均通过安全加密协议 https:// 提供服务。如果在沙箱内尝试请求一个未启用 HTTPS 的测试接口：

// 在线编辑器运行于 https://editor.app
fetch("http://my-test-api.com/users") // HTTP 协议不安全
  .then(res => res.json())
  .catch(err => console.error(err));

此时浏览器会在发送任何网络字节之前，于本地安全审计层直接拦截该请求，并记录如下警告：

Mixed Content: The page at 'https://editor.app/sandbox.html' was loaded over HTTPS,
but requested an insecure resource 'http://my-test-api.com/users'.
This request has been blocked; the content must be served over HTTPS.

三、系统化排查步骤：5步定位限制根因

当在线运行的代码出现异常或网络请求失败时，应按照以下具体步骤有序诊断，迅速查明是沙箱配置问题还是服务端网络策略问题：

图 2: 在线 JavaScript 执行异常诊断与排查步骤流程图

步骤 1：审查控制台（Console）报错特征

打开浏览器的开发者工具（F12），切换到 Console 面板观察报错调用栈：

• 如果报错包含 DOMException 或 Access is denied for this document，说明代码试图使用了 localStorage、sessionStorage、indexedDB 或 document.cookie；
• 如果报错包含 SecurityError: Blocked a frame with origin，说明代码试图访问了 window.parent、top 或调用跨域 iframe 的内部变量；
• 如果报错为 TypeError: Failed to fetch，说明问题发生在网络层，需进一步查看 Network 面板。

步骤 2：检查 iframe 元素声明属性

切换到 Elements（元素）面板，使用审查元素工具选中包裹代码执行环境的 <iframe> 标签，检查其 sandbox 属性包含的值：

• 确认是否包含 allow-scripts。若缺少，脚本将完全不会解析；
• 确认是否缺少 allow-same-origin。缺少该项是导致 window.origin === "null" 的直接原因（这是合理的安全设计，不应随意破坏）；
• 确认是否配置了 srcdoc 或外部域 URL。

步骤 3：在 Network 面板中提取请求详情

切换到 Network（网络）面板，过滤 Fetch/XHR 请求，重新运行触发报错的代码：

• 查看状态列：若请求状态显示为 (failed) net::ERR_FAILED，且没有发出真实的 HTTP 数据包，通常是 Mixed Content 或者是 CORS 预检阶段被浏览器阻止；
• 查看 Request Headers：展开该请求，找到 Origin 字段，确认是否为 Origin: null；
• 查看 Response Headers：检查服务器返回的头部中是否存在 Access-Control-Allow-Origin 以及允许的方法和头字段。

步骤 4：确认协议匹配性

检查请求 URL 的协议是否为 https://。如果当前在线运行平台为 HTTPS，目标 URL 必须同样为 HTTPS，否则会被浏览器的安全混合内容策略直接静默断开。

步骤 5：验证执行结果并闭环

根据排查所得结论，选择下一节介绍的对应工程手段予以修复，随后清空控制台重新执行，确保既无红字报错抛出，又未破坏沙箱对宿主关键资产的安全屏障。

四、可落地的四大实用解决方案

面对沙箱与跨域限制，在不牺牲系统安全性的前提下，工程师通常采用以下四种标准解决方案：

图 4: 在线运行 JavaScript 限制与跨域解决方案选型决策全景图

方案一：搭建 BFF 服务端反向代理（最推荐）

浏览器的同源策略只在客户端生效，服务端与服务端之间的通信不存在任何 CORS 跨域限制。因此，最稳健的做法是由宿主平台提供一个专门的中转接口（例如 /api/proxy）。沙箱代码将目标 URL 作为参数传给中转服务，由中转服务代为发起 HTTP 请求并返回数据：

const express = require('express');
const fetch = require('node-fetch');
const app = express();

// 允许沙箱域名或在同源宿主下提供接口
app.get('/api/proxy', async (req, res) => {
  const targetUrl = req.query.url;
  
  if (!targetUrl || !targetUrl.startsWith('https://')) {
    return res.status(400).json({ error: '仅支持合法 HTTPS 请求' });
  }

  try {
    // 服务端代发 HTTP 请求，不受浏览器同源策略限制
    const response = await fetch(targetUrl, {
      headers: { 'User-Agent': 'OnlineRunner-Proxy/1.0' }
    });
    
    // 设置放行响应头，确保沙箱能够拿到数据
    res.set('Access-Control-Allow-Origin', '*');
    const data = await response.json();
    res.json(data);
  } catch (err) {
    res.status(500).json({ error: '代理请求失败', detail: err.message });
  }
});

app.listen(3000);

此时在沙箱内运行的客户端代码只需请求代理路由：

// 将外部请求封装为经由代理转发
const target = encodeURIComponent("https://api.github.com/users/octocat");
fetch(`https://run.js.com/api/proxy?url=${target}`)
  .then(res => res.json())
  .then(data => console.log("成功获取代理数据:", data.login))
  .catch(err => console.error("请求失败:", err));

方案二：利用 postMessage 实现宿主安全委托通信

如果在线运行环境与宿主页面属于同一个产品系统（如自研在线 IDE 或插件系统），沙箱可以使用 window.parent.postMessage 将网络请求或存储操作委托给具有完整网络权限的宿主页面，由宿主代为拉取后回传：

function requestViaHost(url, options = {}) {
  return new Promise((resolve, reject) => {
    const messageId = Math.random().toString(36).substring(2);

    // 监听宿主回传消息
    function handleMessage(event) {
      if (event.data && event.data.messageId === messageId) {
        window.removeEventListener('message', handleMessage);
        if (event.data.success) {
          resolve(event.data.result);
        } else {
          reject(new Error(event.data.error));
        }
      }
    }

    window.addEventListener('message', handleMessage);

    // 向宿主页面发送委托请求
    window.parent.postMessage({
      type: 'FETCH_PROXY_REQUEST',
      messageId,
      url,
      options
    }, '*'); // 实际中可绑定具体宿主域
  });
}

// 业务调用
requestViaHost('https://api.github.com/users/octocat')
  .then(data => console.log('通过宿主桥接拉取成功:', data))
  .catch(err => console.error('桥接失败:', err));

方案三：注入内存存储垫片（MemoryStorage Polyfill）

针对沙箱中 window.localStorage 访问抛出 DOMException 导致整段代码崩溃的问题，平台可以在加载用户代码前，向沙箱全局环境中注入一个纯内存模拟的 Storage 垫片。该垫片提供与标准 LocalStorage 完全相同的 API：

(function() {
  try {
    // 探测当前环境是否支持真实 localStorage
    window.localStorage.setItem('__test__', '1');
    window.localStorage.removeItem('__test__');
  } catch (e) {
    console.warn('检测到沙箱存储权限受阻，已自动挂载内存 MemoryStorage 垫片');
    
    // 基于 Map 实现内存存储
    const memoryStore = new Map();

    const mockStorage = {
      getItem(key) {
        return memoryStore.has(String(key)) ? memoryStore.get(String(key)) : null;
      },
      setItem(key, value) {
        memoryStore.set(String(key), String(value));
      },
      removeItem(key) {
        memoryStore.delete(String(key));
      },
      clear() {
        memoryStore.clear();
      },
      key(index) {
        const keys = Array.from(memoryStore.keys());
        return keys[index] || null;
      },
      get length() {
        return memoryStore.size;
      }
    };

    // 覆盖全局只读属性
    Object.defineProperty(window, 'localStorage', {
      value: mockStorage,
      configurable: true,
      enumerable: true,
      writable: false
    });

    Object.defineProperty(window, 'sessionStorage', {
      value: { ...mockStorage },
      configurable: true,
      enumerable: true,
      writable: false
    });
  }
})();

挂载此垫片后，测试者编写的 localStorage.setItem('theme', 'dark') 将在内存中正常存取，代码逻辑顺畅执行，不会因为沙箱权限而意外抛锚。

方案四：纯前端接口 Mock 模拟

对于算法练习、组件测试或教学示例，并不一定需要连接真实的外部互联网。通过重写沙箱内的 window.fetch，可以拦截特定路由并返回固定的模拟 JSON：

const originalFetch = window.fetch;

// 定义模拟数据字典
const mockRoutes = {
  'https://api.mock.test/users': [
    { id: 1, name: '张三', role: '前端工程师' },
    { id: 2, name: '李四', role: '架构师' }
  ]
};

window.fetch = async function(url, options) {
  if (mockRoutes[url]) {
    return new Response(JSON.stringify(mockRoutes[url]), {
      status: 200,
      headers: { 'Content-Type': 'application/json' }
    });
  }
  // 非 Mock 路由退回原生网络
  return originalFetch.apply(this, arguments);
};

五、工程实践中的核心原则与注意事项

在设计和维护在线运行环境时，应牢记以下几项核心安全准则：

1. 坚守沙箱边界不妥协：切勿为了“图省事消除报错”而在生产环境沙箱的 sandbox 属性中随意添加 allow-same-origin。沙箱的首要任务是保护宿主系统与用户资产，报错应当在网络架构层（如代理中转或垫片）解决，而非通过牺牲隔离安全性解决。
2. 防御服务端请求伪造（SSRF）：部署 BFF 代理服务时，必须设置严格的外部目标地址白名单，严禁代理请求内网 IP（如 127.0.0.1、10.0.0.0/8、192.168.0.0/16）或内网元数据服务，防止恶意代码借由在线演练场渗透企业内网。
3. 严防 postMessage 伪造：宿主页面监听 message 事件时，必须严格校验 event.origin 以及消息体的格式结构，不得将未经过滤的消息内容直接当作代码执行。