Zero of the 17 third-party scripts I found carried an SRI integrity attribute. I fetched the homepages of 10 major sites, parsed every static <script> tag, and counted: 17 scripts loaded from a third-party host, and not one had an integrity hash that would let the browser reject a swapped file.
The reason to count this week is the DebugBear hijack. On October 29, a page-speed script that Polymarket loaded from an outside vendor was replaced with code that drained about $2.7 million from signed-in users' sessions — selling positions and moving funds — after the attacker's DNS change at the vendor. Polymarket put the affected wallets at 726 and said on October 30 it was returning $3.9 million: the $2.7 million taken plus $1.2 million for losses during the trading pause. The control that exists for exactly this failure is Subresource Integrity: an integrity="sha384-..." attribute on the script tag makes the browser refuse to run the file if even one byte differs from the hash the site author pinned. A swapped script, the whole attack, simply does not execute.
So I measured how often anyone actually uses it. The script fetched each homepage with a browser user agent, collected every <script> tag, and classified each src as first-party or third-party by registrable domain:
site <script> with-src 3rd-party hosts SRI
polymarket.com 181 101 0 0 0
github.com 16 8 8 1 0
nytimes.com 57 9 7 2 0
cnn.com 15 1 1 1 0
google.com 14 2 1 1 0
amazon.com 2 0 0 0 0
reddit.com 1 0 0 0 0
apple.com 19 14 0 0 0
wikipedia.org FETCH FAILED (read timeout)
stackoverflow.com FETCH FAILED (read timeout)
TOTAL third-party scripts: 17, with SRI: 0 (0.0%)
TOTAL <script> tags: 305
Two readings fall out of that table, and they point in opposite directions. First, the 0% is real but narrow: it covers scripts present in static homepage HTML. Polymarket itself shows 0 third-party scripts in its static HTML — its 101 sourced scripts are bundled or same-domain, and the DebugBear script is gone from the page (the homepage HTML contains no mention of DebugBear at all). The attack script arrived through a vendor relationship, not through a tag a static audit would have caught on the day. Second, and more important: the static count is a floor, not a total. Modern sites inject most third-party code at runtime through tag managers and consent banners, after the HTML I fetched has already been served. So 17 understates the live attack surface, and the 0% SRI figure understates it further — dynamically injected scripts almost never carry integrity hashes either, because the injector, not the site author, writes the tag.
That is the uncomfortable part. SRI is a free browser feature, it has existed for a decade, and it defeats the exact attack that just cost Polymarket users $2.7 million — yet on the homepages I could measure, adoption among third-party scripts was literally zero. The honest version of the advice is narrower than "add SRI to everything": pin integrity hashes on the third-party scripts you control in markup, and treat anything injected at runtime — tag managers, A/B tools, chat widgets — as unpinned by construction, because that is what it is. Hudson Rock's advice after the incident was blunter: keep unneeded third-party code off the pages where users make transactions. My count suggests the industry has not even done the easy half of that yet.
Boundaries, kept straight. This is a static-HTML audit of 10 homepages on one afternoon, not a crawl of the live runtime script graph — the real number of third-party scripts executing in a browser session is larger than 17, and the SRI rate on those is unmeasured here. The DebugBear figures ($2.7M, 726 wallets, $3.9M returned) are as reported by The Hacker News and Search Engine Journal and summarized in the sources below, not figures I verified against Polymarket's own incident report. But the direction of the measurement is not ambiguous: the control that stops a swapped script is available, free, and unused in every static case I could check.
Sources: The Hacker News, "Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script" (Nov 1, 2026), and Search Engine Journal, "Hackers Hijacked DebugBear's DNS To Serve Malicious JavaScript," as summarized with primary-source links at https://cybercavetech.com/tech-news/third-party-website-scripts-check/ . The homepage audit, the counts, and the SRI check are from my own run today.
Top comments (0)