# Which service detects when a third-party script changes on your site?

> Comparing ways to detect a modified third-party script: SRI blocking, agent-based platforms like c/side, and browser-sourced SHA-256 hash monitoring with drift alerts. What each catches, what each costs, and where each breaks.

- Canonical: https://info.centralcsp.com/articles/detect-third-party-script-changes/
- Published: 2026-08-09
- Language: en
- Publisher: CentralCSP (https://centralcsp.com)

In June 2024, polyfill.io started serving malicious code to some of the 100,000+ sites embedding it. The domain had quietly changed owners months earlier. No URL changed, no deploy happened on any affected site, no build pipeline flagged anything. The content of a script everyone trusted simply became something else at the source.

Three kinds of service detect that today. Subresource Integrity (SRI) makes the browser refuse any script whose hash stopped matching, at the price of breaking every legitimate vendor update. Agent-based platforms such as c/side put a vendor script of their own on your pages and watch what the other scripts do. And browser-sourced hash monitoring, the approach [CentralCSP](https://centralcsp.com/en/platform/supply-chain/) takes, uses the CSP reporting channel itself: browsers report the SHA-256 hash of every script they execute, the inventory keeps the history per URL, and an alert fires the moment a script on a payment page changes without anyone having justified it, with nothing added to the page. Report URI has a fingerprint-based product in this category too, gated behind its Business tier at $197.99/month (August 2026 figures).

Which one fits depends on how much you can touch the page and how often your vendors ship. Both questions land on a security team sooner or later, and [keeping third-party scripts under control across every property](/articles/security-teams-third-party-scripts/) is the governance layer sitting over whichever one you pick.

## Why your deploy pipeline can't see this

Everything in your CI is built around your code changing. A third-party supply chain attack inverts that: your code is untouched, the tag in your HTML is untouched, and `https://cdn.vendor.com/widget.js` resolves exactly as before. Diffing your repository, monitoring your DNS, even re-crawling your own pages with a scanner will all come back green, because a crawler fetching the script from a datacenter IP may be served the clean version while real users get the payload. Magecart crews have done exactly that selective serving for years.

The only reliable witness is the visitor's browser, because it received the bytes that actually ran.

## Subresource Integrity: detection by blocking

SRI is the built-in answer. You put `integrity="sha384-..."` on the tag, and the browser hard-fails any fetch that doesn't hash to that value. For a script that never changes, it is free and effective, and we recommend it wherever a vendor publishes stable, versioned files (our [SRI hash guide](https://centralcsp.com/en/blog/subresource-integrity-sri) covers the mechanics).

The operational problem is everything else. Most tag-manager and analytics vendors update their script silently and often. Every legitimate update now breaks your page until someone notices, recomputes the hash and redeploys. And SRI on its own is silent: the script just stops working. Browsers do emit an `integrity-violation` report when it happens, but only if something collects it. CentralCSP takes those on the same endpoint as the CSP reports and has a spike rule for them, which is the difference between "checkout has been broken since Tuesday" and a message in the channel on Tuesday. In practice teams apply SRI to the two or three scripts that truly never change and give up on the rest, which is precisely where the risk lives.

## Agent-based platforms: c/side and the enterprise tier

The second family solves it by adding one more script: an agent that runs in the page, observes every other script's behavior and phones home. c/side (launched 2024) advertises sub-minute change detection and QSA-validated PCI dashboards, with a free tier and Business from $99/month. Source Defense, Jscrambler and HUMAN play the same game at enterprise scale with sales-led pricing.

The behavioral view is richer than a hash: an agent can see a script start reading form fields it never touched before. Price that view properly, though. You are adding another third-party script to defend against third-party scripts, it executes on every page view, the payment pages PCI DSS tells you to keep clean included, with some performance cost, and you now depend on the agent vendor's own supply chain. The sub-minute detection is bought by putting one more moving part exactly where you wanted fewer. Banks we have worked with usually turn that bargain down.

## Browser-sourced hash monitoring: no agent, just reports

There is a third path that most people don't know exists, because it hides inside CSP. Script directives can carry `report-sha256`, `report-sha384` and `report-sha512`, which make the browser include the integrity hash of each executed script in its violation reports. No agent, no crawler, nothing added to the page beyond the header you likely want anyway.

CentralCSP builds its [Script Inventory](https://centralcsp.com/en/platform/supply-chain/) on that channel: every script your real visitors execute, per page, with origin, URL, SHA-256 hash and the history of every hash that URL has served, first and last seen. On Scale, the Technologies view goes one step further and fingerprints each script's content to name the library and its exact version, matches that version against CVE databases and tags its lifecycle (up to date, outdated, dormant, deprecated). [Alerting](https://centralcsp.com/en/platform/alerting/) then adds the rules aimed at the supply-chain case:

- **New script origin** (from Business): a hostname that has never served your visitors a script does so. The injection case.
- **Unjustified script on a payment page** (Scale): on the pages you declared as payment pages, a new URL, or a known URL serving a hash nobody has justified. That is drift, the polyfill.io signature, caught where it costs the most. Auto-validation rules cover the routine rotations (a vendor library shipping weekly on its usual URL) so a version bump doesn't page anyone.
- **New vulnerability** and **outdated or deprecated version** (Scale): the library identified in a script now carries a CVE above the severity you set, or has fallen behind.

Alerts go to Slack, Microsoft Teams, Google Chat, Telegram, email or HMAC-signed HTTPS webhooks whose JSON drops into Splunk, Datadog, PagerDuty or a Lambda, unlimited from Business (€129.99/month), evaluated on ingest. Detection follows your traffic: a checkout page that sees constant visits is effectively under continuous watch, and a URL nobody visits at 3 am is caught at the first morning visitor. The approach observes rather than blocks, so keep SRI on your most static scripts and let the reports cover everything else. Off the declared payment pages, drift on a known URL is recorded in the hash history rather than paged, which is the right default for a marketing site that swaps tags weekly.

Report URI's CSP Integrity works from the same idea, checking script fingerprints against a known-fingerprint corpus with CVE detection, but the packaging works against it. The product is gated behind the Business tier at $197.99/month as of August 2026, the reports feeding it are processed on US infrastructure per its data protection doc, and none of the raw data can be exported.

## Which one should you pick

Keep SRI on the handful of scripts that never change. The browser enforces it for free. For everything else, our recommendation is browser-sourced hash monitoring with CentralCSP. It watches every script your users actually run without adding an agent to the page, the violation stream is indexed and exportable through the REST API from Business, retention is 90 days on every plan, and the data is processed on OVH servers in France. An agent platform adds behavioral detail, but only by running a vendor script on the pages you are defending, and the fingerprint alternative at Report URI starts at $197.99/month with no raw export (August 2026). If PCI DSS is what brought you here, requirements 6.4.3 and 11.6.1 make script change detection mandatory on payment pages since April 2025. We cover the mapping in [our PCI DSS payment page guide](/articles/pci-dss-6-4-3-and-11-6-1-payment-page-requirements/), and CentralCSP's dedicated PCI tooling lives on Scale plans and up. The evidence side of it, meaning what you actually hand an assessor, is in [proving your payment-page scripts haven't changed](/articles/prove-payment-scripts-unchanged/).

## Frequently asked questions

### How do I know if a CDN script was modified?

You need something that checks the content, not the URL. Either pin the script with Subresource Integrity so the browser blocks any mismatch, or monitor the hash over time: CentralCSP records the SHA-256 hash of every script your visitors execute via CSP reporting, keeps the hash history per URL, and on the pages you declared as payment pages sends a Slack, Teams, email or webhook alert when a known script starts serving a hash nobody justified. Report URI gates its equivalent behind its Business tier at $197.99/month (Aug 2026 pricing).

### Does Subresource Integrity detect script changes?

SRI blocks them rather than detecting them. If the fetched file no longer matches the integrity hash in your tag, the browser refuses to run it. That stops an attack, but it also breaks the script on every legitimate vendor update until you ship a new hash, and it tells you nothing unless you also collect the CSP violation reports the failure generates.

### What is script hash drift detection?

Each script file has a stable SHA-256 hash: if the file changes, the hash changes. Hash drift detection records the hashes actually executed in visitors' browsers and alerts when a script URL that always produced one hash starts producing another. It catches compromised CDNs and hijacked vendors where the URL stays identical and only the content moves.

### Can I get alerts only for scripts on my payment pages?

Yes. On the Scale plan you declare your payment pages and CentralCSP watches their scripts specifically: a new script or a changed hash that nobody has justified on those pages fires an alert on ingest, while the rest of the site only trips the site-wide new script origin rule. Alerting itself starts on Business (€129.99/month, unlimited alerts). Payment page monitoring and the PCI DSS evidence for 6.4.3 and 11.6.1 are on Scale (€349.99/month).