看起来主站点正在将 Adob​​e Marketing Cloud 中的脚本直接嵌入到页面中。虽然这些脚本是从与主站点相同的服务器加载的，但看起来这些脚本使用 XHR 与外部服务器通信，并根据 uBlock Origin 的日志从 demdex.net 和 2o7.net 下载新脚本。

尤其是从您的银行控制之外的第三方加载和执行新脚本是一个巨大的安全问题。本质上，这些脚本可以完全控制网站，包括阅读您输入的内容、更改提交或显示的内容等。这些本质上是跨站点脚本，只是它们不是偶然发生的，但银行网站的开发人员明确邀请了这些第三方做跨站脚本。

虽然在没有输入敏感信息的网站上使用第三方服务可能是可以接受的，但在传输敏感信息或网站内容意外更改（例如显示不同的帐户余额）时绝对不能接受并可能导致访问者采取不必要的行动。

银行网站几乎不是单一的。一家银行的整体解决方案通常依赖数十个甚至数百个第三方系统。您可能有一个供应商提供的银行主机、两个或三个以上供应商提供的信用卡解决方案、另一个供应商提供的登录解决方案、另一个供应商提供的付款。将这些网站放在一起的工作是巨大的。

银行网站在前端也涉及第三方的情况并不少见。这可以从第三方库只是为了呈现日历控件到提供用户行为分析和风险决策的系统。其中许多供应商通过内容交付网络 (CDN) 提供脚本和内容，这意味着文件可能来自第三方域。

这很危险吗？有可能。如果第三方资源没有通过子资源完整性验证，它们可能被黑客（通过中间人）甚至第三方本身（例如恶意员工）修改。因此，任何在线银行实施都将自己托管内容（即，将第三方文件复制并粘贴到他们自己的 Web 服务器上），或者在某些情况下使用加密散列传送内容，通过引用的节点或节点的integrity属性来表示外部文件。在其他情况下，它们将链接到 CDN，但在 SRI 检查失败时提供本地文件的回退行为（请参阅此 StackOverflow 问题）。scriptlink

我应该担心在银行网站上跟踪域吗？

需要注意的是，在欧盟，欺诈交易的成本由机构承担。因此，网上银行安全的首要任务是保护银行，而不是您。

无论 OP 提出什么架构，您都可以确定它通过了几层风险评估和审查，并且使用 CDN 提供某些内容的决定并非轻易做出的。他们很可能已经正确地实施了它，并且正在使用某种 SRI 方法。你仍然可以担心，但担心应该是最小的。

机会很低，但它可能是一个真正的威胁。最近（2017 年 4 月）发现，波兰一家大型银行 (mBank) 上的跟踪脚本 (Gemius) 将账户余额与其他（标准）跟踪数据一起发送。预期的效果可能是捕获导航（页面标题/部分），因此泄漏本身可能是偶然的。