我正在编写一个内部工具，它将支持其他开发人员编写的插件。理想情况下，这些插件应该有一个 Javascript 组件来允许人们制作小部件。这些小部件操作的某些页面可能包含敏感数据。我要避免的是开发人员编写一个具有 javascript 的插件，该插件将此数据发布到某个外部服务器。但是，对于这些小部件的操作来说，它们必须能够操纵页面上的数据。基本上这些小部件应该只能够影响数据的呈现，但它们不应该能够窃取它。
我看过 adsafe，但这太严格了，因为这些小部件只能操作 adsafe 小部件提供的 dom，因此无法访问它们需要的数据。我还查看了 Google Caja，这可能是一个不错的解决方案，尽管它的交叉编译会使代码在性能关键的环境中执行得更慢（我也没有玩过它，所以我不知道具体是否可以使用它以避免发布）。
我认为“理想”的解决方案可能是某种静态分析工具，可以消除“仅”尝试联系外部服务器的程序，但我欢迎任何可行的建议。
代码本质上是动态的，并且永远不可能控制用户提供的代码的行为。通过允许用户执行 JavaScript，您正在实施跨站脚本 (XSS) 漏洞。XSS 也常用于将用户暴露给Drive By Download攻击，而这种攻击在您的威胁模型中奇怪地缺失了。
减轻 XSS 威胁的一种方法是将用户提供的脚本隔离到子域中，这样他们就无法访问由于同源策略而导致的敏感信息。这无法阻止攻击者对您的 Web 应用程序的用户执行 BeEF或通过下载攻击执行其他类型的驱动器。
您可以使用Content-Security-Policy。这可以添加一些脚本限制。但是，并非所有浏览器都使用它，并且它可能对您来说不够精细。
我最近创建了一个 js 库（https://github.com/asvd/jailed），它可能适合您的目的。思路如下：
不受信任的代码在受限沙箱中执行（Node.js 中的受限子进程，或 Web 浏览器的沙箱 iframe 中的 web-worker）；
沙箱无法访问任何东西，但您可以将一组外部函数“公开”到沙箱中，从而精确定义 API 以及允许不受信任的代码执行的权限；
然后代码可以直接调用这些函数以允许的方式操作或与主应用程序交互（在后台，这实际上是使用消息传递机制模拟的）。
这也可能有点不方便，这意味着如果您希望允许有机会操纵 DOM 节点，例如，您必须根据导出的函数明确地重新描述整个 API。