Third-party JavaScript on your pages: inventory, Subresource Integrity and CSP

Why it matters. When your page loads a script from another company's server (analytics, real-user monitoring, chat, A/B testing, tag managers), the browser runs that code with the same reach as your own: it can read what the user types, change what they see and send requests with their logged-in session. MDN describes the core risk plainly: if an attacker gains control of the third-party host, they can inject malicious content into its files or replace them, which it calls a supply chain attack. The provider's security becomes part of yours, on every page where the tag appears.

A recent example. On 30 October 2026 (Perth time) website-monitoring service DebugBear told customers on X it was affected by a security incident and asked users of its RUM product to remove the embed code from their websites. BleepingComputer reported that malicious JavaScript served from DebugBear's CDN targeted logged-in Polymarket users, and that the script used DebugBear's own infrastructure to receive instructions and send back data. See the CyberStack card for the sourced detail. The lesson for defenders is that the dangerous script came from a host the site already trusted.

Step 1: know what you load

Keep a list of every third-party script on pages that handle sign-in, payment, password reset, account changes or personal data: the URL, the owner inside your organisation, why it is there and who at the vendor can change it. Tag managers deserve their own line, because anyone with publishing rights in the tag manager can add code to production without a release. Remove what has no current owner, and keep monitoring and marketing tags off the most sensitive pages unless there is a clear need.

Step 2: pin the file with Subresource Integrity (SRI)

SRI is a W3C web security specification (the current Subresource Integrity working draft is dated 20 March 2026) that lets you put a cryptographic hash of the expected file in the integrity attribute of a script (or stylesheet) tag. The allowed algorithms are SHA-256, SHA-384 and SHA-512; the browser uses the strongest one you list, hashes what it downloaded, and refuses to run the file with a network error if nothing matches. Cross-origin files checked this way must be fetched with CORS, so the tag also needs a crossorigin attribute and the provider must send a suitable Access-Control-Allow-Origin header. MDN also documents an Integrity-Policy response header that tells the browser to block scripts loaded without integrity metadata, with a Report-Only variant for finding gaps first.

The catch is that SRI only works for a file that does not change underneath you. Many vendors serve a single 'latest' URL that they update at will; a hash on that file breaks the first time they ship, which is exactly the protection you want but rarely what the vendor supports. Ask the vendor for versioned, immutable URLs, or host a reviewed copy yourself and update it through your own change process. Where neither is possible, treat the tag as code you cannot verify and keep it off sensitive pages.

Step 3: limit what can run with Content Security Policy (CSP)

CSP is a response header that tells the browser which sources of script and other resources a page may use. MDN recommends a 'strict CSP' built on nonces (a fresh random value per response that each permitted script tag must carry) or hashes of the permitted scripts, together with object-src 'none' and base-uri 'none'. For external files, a hash-based policy needs the matching integrity attribute on the tag, and MDN notes that hashes must be recalculated whenever the script changes. A policy that simply lists trusted hostnames is weaker: it stops scripts from unknown domains, but it cannot tell a vendor's normal file from a tampered one served from the same allowed host.

Step 4: plan for the vendor's bad day

Write down, before you need it, how to remove each third-party tag quickly (a feature flag, a tag-manager kill switch or a config change that does not need a full release) and who may pull it out of hours. When a provider reports a compromise: remove the tag, purge CDN and page caches, review account actions and API calls made from user sessions during the exposure window, rotate any keys or tokens that were visible to the browser, and decide whether customers must be told under your breach-notification duties. Add the vendor to your third-party risk register with the incident date and how you learned of it.

Desk note: this page is the desk's own guidance built on the W3C Subresource Integrity specification and MDN's Subresource Integrity and Content Security Policy guides (read 30 October 2026). The DebugBear and Polymarket details are as reported by DebugBear and BleepingComputer; see the linked card.