本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Why Third-Party Scripts Are Still the Weakest Link in Modern Web Stacks

Every modern web application is built on an uncomfortable foundation of unearned trust. Engineering teams spend months locking down backend infrastructure, setting up strict database firewalls, enforcing encrypted server channels, and putting code through rigorous multi-stage reviews. Then, right before launching to production, a product manager or marketing lead asks to track user analytics, monitor page-load speeds, or embed a customer support chat widget. Within minutes, a few small script tags are added to the website. Just like that, external code from half a dozen outside companies is invited directly into the browser runtime of every logged-in user. And when one of those external companies gets compromised, no server-side security team on Earth can stop the damage.

现代网络应用程序建立在一种令人不安的、未经证实的信任基础之上。工程团队花费数月时间加固后端基础设施、设置严格的数据库防火墙、强制执行加密服务器通道，并对代码进行严格的多阶段审查。然而，就在产品上线前夕，产品经理或营销主管可能会要求添加用户分析追踪、页面加载速度监控或嵌入客户支持聊天插件。几分钟内，几个小的脚本标签就被添加到了网站上。就这样，来自半打外部公司的代码被直接引入了每个已登录用户的浏览器运行时中。一旦其中一家外部公司遭到入侵，地球上没有任何后端安全团队能够阻止损害。

The recent exploit on Polymarket — where a hijacked performance-monitoring vendor silently drained over $2.7 million from active user accounts in under an hour—is a stark wake-up call. It proves that client-side supply-chain attacks aren’t theoretical. More importantly, it exposes how standard web architecture routinely makes these breaches disastrously easy.

最近发生在 Polymarket 上的漏洞利用事件——一个被劫持的性能监控供应商在不到一小时内悄无声息地从活跃用户账户中窃取了超过 270 万美元——是一个严峻的警钟。它证明了客户端供应链攻击并非理论上的威胁。更重要的是，它揭示了标准的网络架构是如何让这些漏洞变得极其容易被利用的。

The Anatomy of the Attack: What Actually Happened? The Polymarket breach wasn’t caused by a flaw in the platform’s core product, a database leak, or a broken smart contract. The company’s internal servers were never actually hacked. Instead, attackers targeted an external vendor named DebugBear, a third-party tool used to track website speed. By taking control of the vendor’s distribution domain through a domain-name compromise, the attackers swapped out the vendor’s legitimate monitoring file for a malicious one. Because Polymarket’s website was set up to fetch and run that vendor file live on pages where users traded, the injected code executed automatically inside active browser sessions.

攻击剖析：究竟发生了什么？Polymarket 的漏洞并非由平台核心产品缺陷、数据库泄露或智能合约漏洞引起。该公司的内部服务器从未被真正黑入。相反，攻击者瞄准了一家名为 DebugBear 的外部供应商，这是一款用于追踪网站速度的第三方工具。通过域名劫持控制了该供应商的分发域名后，攻击者将供应商合法的监控文件替换为了恶意文件。由于 Polymarket 的网站被设置为在用户交易页面实时获取并运行该供应商文件，注入的代码在活跃的浏览器会话中自动执行了。

The malicious file didn’t need to guess passwords or break encryption key pairs. It simply loaded into the same overall browser space as the rest of the application. Once inside, it quietly: 1. Read active user session data straight out of the browser’s local memory. 2. Accessed the platform’s internal transaction tools already running on the open page. 3. Initiated unauthorized money transfers to attacker wallets using valid, live session tokens. To the receiving servers and verification networks, every single request looked completely legitimate—because it was generated by an authenticated, active user session.

恶意文件不需要猜测密码或破解加密密钥对。它只是加载到了与应用程序其余部分相同的浏览器空间中。一旦进入，它便悄悄地：1. 直接从浏览器的本地内存中读取活跃的用户会话数据；2. 访问已经在打开页面上运行的平台内部交易工具；3. 使用有效的实时会话令牌向攻击者的钱包发起未经授权的转账。对于接收服务器和验证网络而言，每一项请求看起来都完全合法——因为它们是由经过身份验证的活跃用户会话生成的。

Why Standard Security Defense Controls Fail When news of a breach breaks, non-security teams often ask, “Don’t we have web firewalls and security filters to catch this?” In the modern client-side environment, traditional defenses fall short for three key reasons: 1. Security Rules Check Origins, Not Behaviors. Most web security policies rely on allowlists. Teams define a rule that says: “Trust any file delivered from this specific vendor web address.” When attackers took over the vendor’s domain, the web address didn’t change—only the content stored on it did. The user’s web browser checked its allowlist, verified that the web address was on the approved list, and ran the malicious file without hesitation. Allowing an address only verifies where a file comes from, not what it does once it arrives.

为什么标准的防御控制会失效？当漏洞消息传出时，非安全团队经常会问：“我们难道没有网络防火墙和安全过滤器来拦截这些吗？”在现代客户端环境中，传统防御措施因三个关键原因而失效：1. 安全规则检查的是来源而非行为。大多数网络安全策略依赖于白名单。团队定义的规则是：“信任来自该特定供应商网址的任何文件。”当攻击者接管了供应商的域名时，网址并没有改变，改变的只是存储在上面的内容。用户的浏览器检查了白名单，确认该网址在批准列表中，便毫不犹豫地运行了恶意文件。允许一个地址只能验证文件的来源，而不能验证它到达后会做什么。

2. Backend Security Systems Are Blind to the Browser. Firewalls and server scanners inspect incoming traffic heading directly to your own servers. Automated testing scanners evaluate code that your own developers write. Neither of those tools can see or analyze an external script fetched directly by an end user’s browser from an entirely different company’s server.

3. 后端安全系统对浏览器视而不见。防火墙和服务器扫描器检查的是直接发往你自己服务器的入站流量。自动化测试扫描器评估的是你自己开发人员编写的代码。这两种工具都无法查看或分析由终端用户的浏览器直接从完全不同的公司服务器获取的外部脚本。

4. Browsers Suffer from an All-Access Design. By default, web browsers do not separate permissions for different scripts on the same webpage. If your core banking app and a lightweight page-speed tracker run on the same screen, they share the exact same house key. The tracker has full visibility into user input, browser storage, and active buttons on the page. Adding a third-party widget to a financial dashboard is the architectural equivalent of handing your building manager the master key to your personal safe.

5. 浏览器受限于“全权访问”设计。默认情况下，网络浏览器不会为同一网页上的不同脚本分离权限。如果你的核心银行应用程序和一个轻量级的页面速度追踪器在同一个屏幕上运行，它们共享的是同一把“房门钥匙”。追踪器可以完全查看用户输入、浏览器存储以及页面上的活动按钮。在金融仪表板中添加第三方插件，在架构上等同于将你个人保险箱的主钥匙交给大楼管理员。

Architectural Solutions: Securing the Client Side. If web development is going to move past these recurring supply-chain vulnerabilities, engineering teams must stop viewing third-party code as harmless add-ons and start treating it as untrusted software. 1. Require File Verification Hashes. If an application must load files hosted by external vendors, it should enforce cryptographic hash checking. By storing a digital signature of the vendor file on your own servers, the user’s browser can verify that the fetched file matches the expected pattern. If an attacker tampers with the vendor file on their domain, the signatures won’t match, and the browser blocks execution.

架构解决方案：保障客户端安全。如果网络开发想要克服这些反复出现的供应链漏洞，工程团队必须停止将第三方代码视为无害的附加组件，而应开始将其视为不可信的软件。1. 要求文件验证哈希。如果应用程序必须加载由外部供应商托管的文件，则应强制执行加密哈希检查。通过在自己的服务器上存储供应商文件的数字签名，用户的浏览器可以验证获取的文件是否与预期模式匹配。如果攻击者篡改了其域名上的供应商文件，签名将不匹配，浏览器会阻止执行。

2. Sandbox Outside Code Off the Main Thread. Analytics and chat widgets almost never need direct access to the main visual surface or internal data store of an app. Running third-party tools inside isolated background workers isolates them completely from sensitive browser memory, stored login details, and payment buttons.

3. 将外部代码沙箱化并移出主线程。分析和聊天插件几乎从不需要直接访问应用程序的主视觉界面或内部数据存储。在隔离的后台工作线程中运行第三方工具，可以将它们与敏感的浏览器内存、存储的登录详情和支付按钮完全隔离开来。

4. Self-Host External Dependencies. Rather than pointing websites to live external URLs that can change at a moment’s notice, development teams should download, audit, and host third-party files on their own secure infrastructure. Bringing third-party code under internal deployment pipelines ensures that outside updates cannot go live without automated safety checks and manual approval.

5. 自托管外部依赖项。开发团队不应将网站指向随时可能更改的实时外部 URL，而应下载、审计第三方文件，并将其托管在自己的安全基础设施上。将第三方代码纳入内部部署流水线，可以确保外部更新在没有经过自动化安全检查和人工审批的情况下无法上线。

6. Isolate Sensitive Session Storage. Critical authentication tokens and payment actions should never sit in general browser storage where any script on the page can freely read them. Storing key credentials inside locked-down, restricted-access browser containers prevents rogue scripts from harvesting user access even if they manage to breach the page.

7. 隔离敏感的会话存储。关键的身份验证令牌和支付操作绝不应存放在通用的浏览器存储中，因为页面上的任何脚本都可以随意读取它们。将关键凭据存储在锁定且受限访问的浏览器容器中，可以防止恶意脚本在即使成功入侵页面的情况下也无法窃取用户访问权限。

The Big Takeaway for Product Teams. Client-side supply-chain attacks succeed because web creators…

产品团队的核心启示。客户端供应链攻击之所以能够成功，是因为网络创作者……