大多数电子商务网站在支付页面上都包含谷歌分析代码。支付页面也是使用 JS 工具（例如 optimizely 或 visual-website-optimizer）进行 a/b 测试的主要候选者。

还有与第三方产品订阅引擎的集成，这些引擎依赖于 JS 通过 https 将 CC 数据从购物车传回服务的母船（例如 Ordergroove）。

许多电子商务平台可以很容易地通过模板系统在所有页面上包含一个小部件，但很难在转换漏斗中仅排除一个页面。

一种选择可能是将您的小部件包装在一些 JS 中，最终在 URL 与特定模式匹配的情况下不包括您的远程代码。这将允许您的客户将代码放置在任何地方（在所有模板中），同时轻松防止您的代码在特定页面上执行。这可以作为替代安装说明提供。

如果我理解正确，您正在尝试通过建议您自己的代码不应在某些页面上运行来主动保护您的客户免受潜在风险的感知。你的努力可能没有必要。

让您的客户通过让他们自己选择来保护自己。将您的文档更改为“在每个页面上安装，但可以安全地省略带有 CC 进程的页面”。

我还没有遇到任何安全最佳实践，即“在呈现包含个人/信用卡数据的网页时应省略所有 JS 脚本”。

如果小部件和客户信用卡数据在同一页面上，是否有办法破解您的 JS 小部件以构成威胁？或许。您需要真正审查小部件，以及它是如何受到损害的——这更像是一个设计问题，而不是一揽子规则。

就妥协的例子而言——它们总是很少而且相差甚远——除非它们是臭名昭著的，否则大多数公司都不会公开它们。最好的办法是检查 OWASP 指南和漏洞发布站点，看看是否有任何特定的 JS 警报连接到您的小部件中的任何内容。

就生活规则而言 - 常见的最佳实践是保持您的实现和接口简单、清晰，并对其进行仔细审查。将 JS 小部件放在不需要的地方可能会因为增加不必要的复杂性而违反该前提。OTOH - 要求客户找到一种仅从支付/登录页面省略它的方法可能会导致客户代码中的风险导致复杂性。如果不坐下来了解每个客户的架构，就无法判断。

许多这样的“有用”小部件通常使用直接跨站点<script>标签加载，在您明确确定法律责任事项之前，这是一个真正的不做。通常，所有责任都由卡处理实体（网络商家或卡处理网关）而不是小部件作者实体承担。

作为商户或 PCI 卡处理网关，允许您在我们的卡数据处理页面上使用您的 3rd 方 JS 需要您提供过去、现在和未来的商业保险证明的全额赔偿，以涵盖对我们业务的潜在责任。实际上，如果你“说”有“程序”来阻止流氓员工在 JavaScript 中做坏事，这实际上并不重要，重要的是企业之间的合法行为。这是 PCI 存在将责任从发卡机构/卡网络转移到商家/卡处理器的主要原因。

另一种策略是要求此类小部件作者提供静态数据的 ZIP 下载，商家或 PCI 卡处理网关技术工程师可以审计/检查可能存在的问题和恶意活动。然后从商家自己的系统提供这个静态版本的小部件。这当然意味着更新它对小部件作者来说是一件痛苦的事，因为他们需要确保长期的向后兼容性或冒着惹恼客户的风险。因为通常需要昂贵的 Web 开发技能的商家永远不会更新它。

另一个策略是小部件作者提供一个真正受支持的 API，电子商务商家可以使用受控代码与小部件作者系统进行交互。这将类似于静态 JS，但在服务器端处理。小部件作者远离此解决方案，因为与懒惰的添加<script>标签和跨站点加载相比，商家采用小部件通常是一个过于昂贵的选择。

替代方法通常要容易得多，只需不使用这样的小部件即可避免风险。

为了解释攻击向量，邪恶的小部件作者的托管系统可能会为不同的用户提供不同版本的 JS，可能使用 Referrer 标头、随机性、国家/地区、一天中的时间等……所以万分之一的点击获取 JS 代码的邪恶版本。但所有随意的检查似乎都提供了正确的 JS 代码版本。

像所有的 JS 代码一样，邪恶版的 JS 可以通过将自身附加到页面的表单来读取提交过程中的所有表单数据字段。然后，当不知情的客户（不会有警报或警告）执行提交操作时，表格上的所有数据（包括 CVV/CSC、地址信息以及常用卡数据）都会转发到多个网站。然后将数据复制到它应该去的站点（商家或 PCI 卡处理网关）以及为邪恶目的收集数据的邪恶站点。

IFRAME 也不是完全安全的封装机制，过去存在的问题是允许不应该被邪恶的 JS 代码规避的事情。不是每个人都会更新他们的浏览器。

没有多少是的，我们有“有用的”小部件作者的“安全”程序在出现问题时会帮助符合 PCI 的实体；并且不要被愚弄。

<script>我个人已将其在呈现或接收安全性（用户名/密码）或持卡人数据的页面上的直接第三方跨站点元素 的至少两个英国运营的 PCI 兼容卡处理器上提请注意。对他们来说，问题在于，由于无能而导致的违规行为，给他们的业务和不良宣传带来风险是不值得的。

当您为商户会计部门提供安全的系统和网络以访问支付数据但只允许通过防火墙/代理进行互联网连接时，这些事情很快就会引起您的注意，并且白名单只能访问他们希望使用的特定系统，它令人惊讶的是有多少不应该打破的东西。

要求一个违规的例子是徒劳的，没有人做广告这样的事情。

假设的技术修复（或根据您的观点咆哮）

HTML 真正需要的是原始源服务器能够提供一个或多个校验和（MD5/SHA1/等）和目标脚本的长度信息。这样，消费网站就可以完全控制浏览器将从服务网站接受的确切副本。

<script src="http://mostly.trusted-site.com/useful-script.js" security:checksum="md5:0123456789abcedf;sha1:0123456789abcdef0123;length:543" security:options="load-from-cache-from-anywhere-matching-checksum;no-send-referrer-header;no-use-cookies;no-use-etag;high-security"></script>

此脚本标签是假设的（不要使用），但 HTML 需要向其移动。它用于说明问题域中潜在的未来 HTML5+ 修复。

现在目标站点无法更改我们下面的内容，他们可以看到点击量并提供内容。互联网上的多方将独立审核相同的代码，允许许多人对相同的 JS 代码进行同行评审，因为您可以围绕校验和值建立信任。

允许多个哈希支持重叠迁移到更安全/更长/更广泛支持的哈希，也减少了理论上的冲突机会。

允许从具有相同校验和匹配的任何替代网站的缓存加载（允许零命中 CDN，这是您可以获得的最快 CDN，最后您可以再次回到您的服务器）。因为您可以拥有自己的 jquery.js 本地副本，但允许客户端浏览器在从另一个网站加载时完全从缓存中满足脚本。因为对于大多数用户来说，jquery.js 在任何服务器上都不会受到任何影响（甚至不会重新验证），因为它将从缓存中解析。

获取控制客户端浏览器在访问 URL 以下载脚本时默认发送的可识别信息。您可以在没有 Referrer 标头的情况下点击它，从不发送或存储任何 cookie，与 ETag 等一样。我说明了“no-”的使用，这意味着默认允许这些事情，默认应该是相反的，所有事情都被禁止除非允许。“否”是为了说明消费网站可以获得什么样的信息控制权。

在这种情况发生之前，只需将 JS 复制到您的网站中（在您审核之后）