静态站点第三方脚本沙箱隔离与可信域名白名单实践

前言

在上一篇我们落地了 SRI 子资源完整性校验，解决自有 JS/CSS 的篡改风险。但在实际静态页面开发中，经常会引入第三方脚本：统计埋点、地图组件、在线客服、评论组件等。这类外部脚本不受我们管控，无法使用 SRI 做全量保障，一旦第三方域名被劫持、脚本投毒，会直接污染整个页面上下文，甚至窃取页面数据。

本文基于校园景点静态导览站，搭建一套「可信域名白名单 + 沙箱隔离 + CSP 策略」的防护方案，把第三方脚本的风险边界收束起来，和之前的资源校验、SRI、离线缓存体系打通。

核心痛点

1. 第三方脚本拥有和主页面相同的 DOM、Cookie 访问权限，权限过大；
2. 无法控制第三方服务的发布、劫持、版本变更；
3. 容易不小心引入未审核的外链脚本，构建阶段缺少拦截；
4. 第三方脚本异常、阻塞加载，拖慢页面 LCP、交互响应。

一、基础方案：CSP 内容安全策略 + 可信域名白名单

CSP 是浏览器原生安全机制，通过响应头或者 meta 标签，声明允许加载资源的来源，不在白名单内的脚本、样式、iframe 直接被浏览器拦截。

页面内 Meta 方式配置（适合静态站点，无需配置服务端头）

<meta http-equiv="Content-Security-Policy" content="
  default-src 'self';
  script-src 'self' [https://stats.example.com](https://stats.example.com);
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: [https://cdn.example.com](https://cdn.example.com);
  frame-src [https://map.example.com](https://map.example.com);
  connect-src 'self' [https://api.stats.example.com](https://api.stats.example.com);
  object-src 'none';
  base-uri 'self';
">

字段说明：

• default-src 'self'：默认仅允许本站资源；
• script-src：脚本白名单，只放经过审核的第三方统计域名；
• frame-src：iframe 沙箱域名，地图、评论组件放在这里；
• object-src 'none'：禁止插件、Flash 等高危对象；
• 生产环境尽量避免 'unsafe-inline'，如果内联脚本不可避免，搭配 nonce 方案。

注意：CSP 会和 SRI 协同生效，SRI 校验失败 或者 CSP 不匹配，资源都会被拦截，双重防护。

二、高风险第三方：iframe 沙箱隔离

对于地图、评论、客服这类非强侵入但不可信的组件，不要直接引入脚本，改用 <iframe sandbox> 隔离，切断和父页面的上下文连通。

沙箱标签示例

<iframe
  src="[https://map.example.com/campus](https://map.example.com/campus)"
  sandbox="allow-scripts allow-same-origin"
  referrerpolicy="no-referrer-when-downgrade"
  loading="lazy"
></iframe>

sandbox 权限最小化原则：

• 默认不加任何权限：iframe 内脚本无法执行、表单无法提交；
• allow-scripts：允许执行内部 JS；
• allow-same-origin：允许 iframe 访问自身源（按需开启，能不开就不开）；
• 禁止随意添加 allow-top-navigation、allow-top-navigation-to-custom-protocols，防止劫持父页面跳转。

iframe 内页面单独维护一套 CSP，父页面和子 iframe 之间使用 postMessage 做受控通信，定义固定消息协议，不开放自由通信。

postMessage 受控通信封装示例

父页面：

// 只信任预先配置的目标域名白名单
const TRUSTED_IFRAME_ORIGIN = "[https://map.example.com](https://map.example.com)";
const iframe = document.querySelector("iframe");
iframe.contentWindow.postMessage({type: "load-campus", id: "campus-01"}, TRUSTED_IFRAME_ORIGIN);

window.addEventListener("message", (evt) => {
  if (evt.origin !== TRUSTED_IFRAME_ORIGIN) return;
  const data = evt.data;
  if (data.type === "marker-click") {
    console.log("景点标记点击：", data.point);
  }
});

iframe 内部：

const PARENT_ORIGIN = "[https://campus-site.example.com](https://campus-site.example.com)";
window.addEventListener("message", (evt) => {
  if (evt.origin !== PARENT_ORIGIN) return;
  // 处理父页面指令
});

核心约束：每次校验消息来源 origin，拒绝未知域名的消息。

三、构建阶段脚本：自动检查第三方外链，强制匹配白名单

复用我们之前的 Node 资源检查脚本，新增第三方域名白名单校验，在 CI 阶段拦截未备案外链。

新建配置 asset-allowlist.json

{
  "script": ["[https://stats.example.com](https://stats.example.com)"],
  "frame": ["[https://map.example.com](https://map.example.com)"],
  "img": ["[https://cdn.example.com](https://cdn.example.com)"]
}

校验脚本片段：

const fs = require('fs');
const allowlist = JSON.parse(fs.readFileSync('./asset-allowlist.json','utf8'));

function checkThirdPartyLinks(html) {
  const scriptLinks = [...html.matchAll(/script.*src="(https:\/\/.*?)"/g)].map(m=>m[1]);
  const frameLinks = [...html.matchAll(/iframe.*src="(https:\/\/.*?)"/g)].map(m=>m[1]);

  for(const url of scriptLinks) {
    const host = new URL(url).origin;
    if(!allowlist.script.includes(host)) {
      throw new Error(`❌ 非法第三方脚本域名：${host}，不在白名单内`);
    }
  }
  for(const url of frameLinks) {
    const host = new URL(url).origin;
    if(!allowlist.frame.includes(host)) {
      throw new Error(`❌ 非法iframe域名：${host}`);
    }
  }
}

集成进 CI，只要提交代码引入了未录入白名单的第三方脚本，构建直接失败，防止不小心粘贴来路不明的脚本。

四、和已有离线缓存体系的适配规则

第三方资源不建议进入 Workbox 离线缓存，原因：

1. 第三方资源更新不受我们控制，版本、哈希不可控；
2. 第三方域名如果宕机、变更，缓存会长期留存失效资源；
3. CSP + 沙箱已经管控访问权限，离线能力优先保障自有站点核心内容。

配套规则：

• Workbox runtimeCaching 配置中，跳过白名单第三方域名，不缓存；
• 第三方脚本增加 async / defer，避免阻塞主渲染流程；
• 增加超时兜底，第三方脚本加载超时后，降级隐藏对应组件，不阻塞整个页面。

<script src="[https://stats.example.com/sdk.js](https://stats.example.com/sdk.js)" async></script>

五、降级、监控与异常告警

1. CSP 违规上报：使用 report-uri 收集违规访问日志，先审计再拦截；

<meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'self'; report-uri /csp-report">

上线初期先用 Report-Only 模式，只上报不拦截，确认无业务报错之后，再切换为正式拦截模式。

2. 第三方组件加载失败降级：

// iframe 加载失败兜底
iframe.onerror = () => {
  iframe.style.display = 'none';
  document.querySelector('#map-tip').innerText = "地图组件加载失败，请稍后重试";
};

六、工程权衡

✅ 收益

• 把第三方脚本权限隔离，缩小攻击面；
• 构建 + 浏览器双层校验，防止随意引入未知外链；
• 和 SRI、资源白名单、缓存方案串联，安全体系完整；
• 最小权限原则，iframe 按需开放能力。

⚠️ 代价与坑

• CSP 策略比较严格，内联脚本、内联事件（onclick）会直接拦截，改造存量页面成本高；
• iframe 通信需要维护消息协议，开发复杂度上升；
• 很多第三方 SDK 对 CSP 兼容性差，需要提前调研。

总结

整套链路现在扩展为：
资源路径白名单 → 增量发布 & 图片压缩 → 性能埋点观测 → Workbox 离线缓存 & GC → SRI 自有资源防篡改 → CSP + iframe沙箱隔离第三方脚本。

自有资源靠完整性哈希保护，外部不可信资源靠访问控制、沙箱隔离，形成分层防御。