Chrome扩展能否安全地向沙箱化iframe注入内容脚本？

针对你遇到的Chrome扩展垫片脚本无法在无allow-scripts的沙箱iframe中运行，且父框架可绕过垫片访问原生API的问题，提供以下几种可行方案：

方案1：临时修改沙箱属性注入脚本后恢复 #

通过动态给沙箱iframe添加allow-scripts权限，注入垫片后立即移除该权限，确保仅扩展脚本能执行，不破坏网站原有沙箱隔离：

1. 配置扩展权限：在manifest.json中添加scripting权限和<all_urls>的host_permissions
2. 父框架内容脚本逻辑：

// content.js（父框架注入）
document.addEventListener('DOMContentLoaded', async () => {
  const sandboxIframes = document.querySelectorAll('iframe[sandbox]:not([sandbox*="allow-scripts"])');
  for (const iframe of sandboxIframes) {
    const originalSandbox = iframe.getAttribute('sandbox');
    // 临时添加允许脚本执行的权限
    iframe.setAttribute('sandbox', `${originalSandbox} allow-scripts`);

    // 等待iframe文档就绪
    await new Promise(resolve => {
      if (iframe.contentDocument.readyState === 'loading') {
        iframe.addEventListener('load', resolve, { once: true });
      } else {
        resolve();
      }
    });

    // 注入垫片脚本到iframe的MAIN世界
    await chrome.scripting.executeScript({
      target: { frameIds: [iframe.frameId] },
      files: ['scripts/shim.js'],
      world: 'MAIN'
    });

    // 恢复原沙箱配置，移除脚本权限
    iframe.setAttribute('sandbox', originalSandbox);
  }
});

方案2：代理拦截父框架对iframe的API访问 #

不需要修改iframe沙箱属性，直接在父框架中拦截所有对iframecontentWindow的访问，用代理包装原生window对象替换目标API：

// content.js（父框架注入）
const originalContentWindowGetter = Object.getOwnPropertyDescriptor(HTMLIFrameElement.prototype, 'contentWindow').get;

Object.defineProperty(HTMLIFrameElement.prototype, 'contentWindow', {
  get() {
    const realWindow = originalContentWindowGetter.call(this);
    const sandboxAttr = this.getAttribute('sandbox');
    
    // 仅处理无allow-scripts的沙箱iframe
    if (sandboxAttr && !sandboxAttr.includes('allow-scripts')) {
      return new Proxy(realWindow, {
        get(target, prop) {
          // 替换你要拦截的目标API
          if (prop === 'yourTargetAPI') {
            return (...args) => {
              // 这里添加你的垫片逻辑
              console.log('API调用被拦截:', args);
              // 可选：调用原生API
              return target[prop].apply(target, args);
            };
          }
          return Reflect.get(target, prop);
        }
      });
    }
    return realWindow;
  }
});

该方案的优势是完全不改动网站的沙箱配置，仅拦截父框架对iframe API的直接访问，适配沙箱iframe无内部脚本的场景。

方案3：结合声明式内容规则自动注入 #

利用Manifest V3的declarativeContent规则，自动检测沙箱iframe并触发脚本注入，可配合方案1使用：

1. 更新manifest配置：

{
  "manifest_version": 3,
  "permissions": ["scripting", "declarativeContent"],
  "host_permissions": ["<all_urls>"],
  "background": {
    "service_worker": "background.js"
  }
}

2. 后台服务工作者逻辑：

// background.js
chrome.runtime.onInstalled.addListener(() => {
  chrome.declarativeContent.onPageChanged.removeRules(undefined, () => {
    const rule = {
      conditions: [
        new chrome.declarativeContent.PageStateMatcher({
          pageUrl: { urlMatches: '.*' },
          css: ['iframe[sandbox]:not([sandbox*="allow-scripts"])']
        })
      ],
      actions: [
        new chrome.declarativeContent.RequestContentScript({
          files: ['scripts/shim.js'],
          allFrames: true,
          world: 'MAIN'
        })
      ]
    };
    chrome.declarativeContent.onPageChanged.addRules([rule]);
  });
});

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