没有关于在您的网站上是否有 3rd 方 Javascript 的特定 PCI 要求。

就个人而言，我不会将分析提供商视为 PCI DSS 下的 PCI 服务提供商。

但是，您的自定义网站需要安全开发 (6.5)，并通过安全评估进行审查或在 WAF (6.6) 的保护下运行。

此外，还有漏洞扫描 (11.2) 和外部渗透测试 (11.3.1) 的要求。

根据这些要求之一，托管您网站的第三方库应被标记为漏洞。在正常的非 PCI 安全测试期间，这通常会表述为存在第三方库，并且应审查此风险以确保该库是受信任的，并且托管它的域也是受信任的，如果这是一个外部域。如果第三方域不受信任，或者它受到威胁，那么这将对您的环境和您的 PCI 合规性构成风险。也就是说，托管在 google.com 上的东西可能没问题，但托管在其他地方的东西可能不行。

在安全测试期间，这通常最初被渗透测试者列为低风险漏洞。但是，它应该由企业审查。如果您的企业接受这种风险，那么只需将其记录下来。如果您认为这是一种无法接受的风险，那么您应该记录为减轻这种风险而采取的步骤。例如，通过对第三方脚本进行代码审查，然后在本地托管脚本，而不是从第三方域中获取。此外，现在广泛支持浏览器子资源完整性，如果远程脚本被更改，浏览器会拒绝它们：https ://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

PCI DSS 主要是关于记录您如何处理每项要求的精神，而不是黑名单或白名单。然后，如果您接受了审计，您可以通过您的业务决策流程进行 QSA，以证明您如何满足上述要求。

_{免责声明：我不是 QSA，更重要的是，我不是您的 QSA。只有您合格的 QSA 才能准确评估您在 PCI DSS 下的责任，因为他们将全面了解您的业务及其与您的卡处理活动的关系。}

我不是 QSA。您应该就此事咨询您的 QSA。

我完全同意从不安全的来源提供 javascript 作为包含 PCI-DSS 范围内数据的页面的一部分，不应通过警报 QSA 的要求。我会更进一步说，同一会话中的其他页面不应包含不安全的 javascript。

我可能过于保守，但我会比这更进一步。如果我是评估员，则执行服务器或客户端包含的任何内容都不会通过集合。考虑到您无法控制的这个来源可以在您不知道他们已经这样做的情况下更改内容。您建议采用什么机制来测试该外部内容的安全性？我发生了广泛而丑陋的潜在攻击。您如何可靠地确保每次包含它都是安全的？

作为替代方案，可以考虑将内容复制到您自己的服务器，检查其安全性，然后直接提供服务，而无需从第三方动态加载。实际上，这使它成为您网站的一部分，并受制于您的变更控制流程。

PCI DSS 3.1 要求 #12.8 状态

“是否维护和实施了管理与持卡人数据共享或可能影响持卡人数据安全的服务提供商的政策和程序……”

在检查分析是否属于范围时，请考虑以下几点：

• 分析提供商肯定是在提供服务，因此应该被视为服务提供商。PCI 合规指南进一步强化了这一点，参考了​​ PCI 服务提供商的定义：

“非支付品牌的商业实体，直接参与持卡人数据的处理、存储或传输。这还包括提供控制或可能影响持卡人数据安全的服务的公司。（来源：www.pcisecuritystandards.org )"

• 外部 javascript 肯定有可能影响您的 PCI 数据的安全性。（见 JaimeCastells 的回答）

如果您需要让 QSA 审查该要求，请使用他们的意见。如果您的 PCI 级别不需要 QSA，则您需要在彻底研究问题后根据您的最佳理解做出决定（并可选择聘请 QSA 顾问）。

主要担心的是您必须信任谷歌或任何其他帮助您跟踪用户的第三方。当您以严格的方式布置 PCI DSS 时，您有责任确保只有符合 PCI DSS 的实体才能访问持卡人数据或任何敏感数据。因此，不允许从第三方加载不合规的脚本。合规性必须由 AOC 证明。

但是，您通常可以做的是将跟踪脚本托管在您的服务器上。这意味着您可以评估一次相应的脚本没有窃取卡数据。当您托管脚本时，您拥有控制权，并且不需要 AOC。通常，实际跟踪数据通过图像传递给第三方。因此，在控制脚本时，您可以控制哪些数据会离开您的环境，因此您会变得合规。