--- title: "Client-side supply chain & Magecart protection" description: "Inventory every script real browsers run, identify the library, version and known CVEs in each, and get alerted the moment one changes. No agent, no proxy." url: "https://next.centralcsp.com/en/platform/supply-chain/" lang: "en" --- Supply-chain security # Every script your visitors run, and what's inside it. Your firewall never sees the third-party scripts in your visitors' browsers. We do: every script, its library and version, and the moment one changes or picks up a CVE. [Start free trial](https://app.next.centralcsp.com) [Book a demo](https://next.centralcsp.com/en/contact/?topic=demo) - 0 scripts added Browsers report natively - Real visitor traffic Not a crawler snapshot - CVE detection Fingerprinted from content - EU data residency France, on OVH The threat ## The breach that never touches your server. In a client-side supply-chain attack, the vendor gets compromised and your page delivers the payload. Your servers stay clean, your logs stay quiet, and the damage happens in your visitors' browsers. Three incidents, three routes in. 1. ### Polyfill.io, 2024 The polyfill.io domain changed hands in February. By June, the CDN behind it was injecting malicious redirects into pages on 100,000+ websites that embedded one script tag. The code dodged admin users and analytics tools, so sites that only tested their own pages saw nothing. [Sansec's report](https://sansec.io/research/polyfill-supply-chain-attack) 2. ### British Airways, 2018 Magecart attackers edited roughly 22 lines of a Modernizr file on ba.com. For 15 days, every payment form fed cards to an attacker domain. About 400,000 customers were hit; the ICO fine closed at 20 million pounds. [The ICO's penalty notice](https://ico.org.uk/media2/migrated/2618421/ba-penalty-20201016.pdf) 3. ### npm chalk and debug, 2025 18 packages with 2.6 billion combined weekly downloads shipped malicious versions after one maintainer got phished. The payload ran in end users' browsers, hooking fetch and wallet APIs. Every build-time check passed at install; the attack ran after the build. [Aikido's write-up](https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised) How it works ## One response header in. Every script accounted for. No agent to load, no proxy in your delivery path, no robot visiting your site. Your real visitors' browsers are the sensors. 1. MyEndpoint.report.centralcsp.com 01 - Collect ### Browsers report every script they run Add one response header. From then on, real visitors' browsers report the URL and hash of every script your pages execute: first-party, third-party, and the tag your tag manager loaded last night. 2. 02 - Analyze ### We identify what's inside each script Each script's content is fingerprinted and analyzed to identify the library, framework or vendor behind it, and its version. That identity is checked against known CVE databases and lifecycle status: outdated, unmaintained, end-of-life. 3. 03 - Act ### Changes and CVEs become alerts A new script, a changed hash, a new outbound origin or a fresh CVE pings Slack, Teams, Google Chat, Telegram or email as browsers report it. Fix the finding, or block the vector with a CSP built from the same reports. ### An inventory built by your real traffic. Skimmers cloak: they fire on real checkouts in real sessions and stay dormant for crawlers and sandboxes. CentralCSP's inventory comes from what actual visitors' browsers executed, so a script that only misbehaves in production is still on the list. - First-party and third-party scripts, per page - Last-seen times from live traffic - New scripts flagged the moment they appear ### A CVE in a marketing tag is still your CVE. Knowing a script's filename tells you nothing about the jQuery inside it. CentralCSP fingerprints each script's content, resolves the library and version it contains, and holds it against CVE databases and maintenance status. You patch the vulnerable version before someone else finds it first. - Content fingerprinting, not just URL matching - Known CVEs matched to the exact version - End-of-life and unmaintained versions flagged ### The SBOM your build pipeline can't produce. Your CI scans what's in the repo. The tag manager's payload, the chat widget and the analytics snippet never pass through it, and the npm compromise of September 2025 cleared every build-time check before doing its damage in browsers. This SBOM lists what actually ran client-side. - Technologies and versions from live pages - Covers scripts that never touch your repo - Export it for security reviews and audits ### Data leaving the page is a report, not a mystery. Web skimming has two tells: a file that changed, and data flowing to an origin you never approved. Browsers can report both. An integrity violation fires when a script stops matching its SRI hash; a connection report fires when the page talks to an undeclared origin. - Outbound connections to unknown origins reported - SRI mismatches reported by the browser itself - Hash changes tracked script by script Prevention ## Detection tells you. Configuration stops it. The same reports that build your inventory harden your policy: lock down what can load and where data can go, then let the browser enforce it. ### A CSP from real traffic The CSP builder turns collected reports into a policy that fits your site: script sources locked to what you actually use, connect-src and form-action closed to unknown origins, so a skimmer has nowhere to send the data. - Built from production reports - Exfiltration destinations locked down - Report-only first, enforce when clean [See the CSP builder](https://next.centralcsp.com/en/platform/csp-builder/) ### Integrity on your assets Pin your static scripts with Subresource Integrity and a swapped file refuses to run. Browsers report every mismatch, so tampering surfaces even where you can't pin. - SRI hashes generated in seconds - Integrity violations reported live - Covers the polyfill.io failure mode [Generate SRI hashes](https://next.centralcsp.com/en/tools/sri-hash/) ### Headers graded continuously The free scanners grade your CSP and security headers like an attacker reads them: which origins may run code, which destinations may receive data, what reporting you'd have during an incident. - CSP and header scanning - Reporting setup verified - Free, no account needed [Scan your headers](https://next.centralcsp.com/en/tools/security-headers/) Approaches ## Three ways to watch your scripts. Every client-side security product answers one question differently: what do you have to add to your site to get visibility? Here is the honest comparison the vendors skip. Comparison of client-side security deployment models | | CentralCSP | Injected agent | Proxy delivery | | --- | --- | --- | --- | | Adds nothing to your page | Yes: Nothing, a header | No: Its own script | No: A proxy in the path | | Sees real visitor sessions | Yes: Every browser reports | Yes: While its script runs | Partially: Proxied traffic only | | Catches cloaked skimmers | Yes: Fires on real checkouts | Partially: Unless evaded first | Partially: If payload inspected | | Blocks malicious scripts inline | Partially: Via your CSP | Yes: In-browser blocking | Yes: Blocks at the edge | | Adds no page weight or latency | Yes: Zero bytes added | No: Runs on every page | No: Latency per fetch | | Adds no new attack surface | Yes: Never in the page | No: One more third party | No: It serves your code | Check your exposure ## How exposed is your site right now? Two minutes: see which origins can run code on your pages today, and whether you would even hear about it when one goes bad. Scan my site Free, no account needed. Results land on a shareable page. Trusted by teams across the world ## Taking payments? This is now mandatory. Since March 2025, PCI DSS v4 requires a justified inventory of every payment page script (6.4.3) and alerts on unauthorized changes (11.6.1). That is this page's feature set, pointed at your checkout, with the evidence exports your assessor asks for. [See PCI DSS evidence](https://next.centralcsp.com/en/platform/pci-dss/) - Script inventory with justifications - Change and tamper alerts - CSV and PDF evidence exports - SBOM for the assessor FAQ ## Frequently asked questions Client-side supply-chain attacks and how we catch them, answered. ### What is a client-side supply-chain attack? An attack that reaches your users through code your pages load from someone else: a third-party script, a CDN, a tag manager, an npm package that ends up in your bundle. The vendor gets compromised, your page delivers the payload, and the theft happens in the visitor's browser. Your servers are never breached, which is why server-side tooling misses it. ### Can a Content Security Policy stop Magecart attacks? It stops a lot: a strict CSP blocks scripts from origins you never approved and, through connect-src and form-action, blocks data from being sent to the attacker's server. What it can't judge is an approved vendor turning malicious, which is exactly what happened to British Airways. That is why CentralCSP pairs the policy with a script inventory, content fingerprinting and change alerts: the CSP closes the doors, script monitoring watches the vendors you let in. ### Why don't my WAF or my dependency scanner catch this? They stand in the wrong places. The WAF inspects traffic to your servers, and a skimmer sends data from the visitor's browser straight to the attacker's domain, so the WAF never sees the request. Your dependency scanner checks the code in your repository, and the tag manager's payload or the chat widget never passes through it. The only place every script is visible is the browser that executes it, and that is where CentralCSP's reports come from. ### How does CentralCSP detect CVEs in my scripts? Browsers report the URL and hash of every script your pages execute. CentralCSP fingerprints each script's content and runs its own analysis to identify the library or framework inside and its exact version, then checks that identity against known CVE databases and lifecycle data. You get the finding attached to the script and page it runs on: a known CVE, an end-of-life version, or a library that stopped being maintained. ### What is a client-side SBOM? A software bill of materials for what runs in the browser rather than what sits in your repository. A build-time SBOM stops at your bundle; the client-side SBOM also covers the scripts your pages pull in at runtime, from tag managers to support widgets, with the version and vulnerability status of each. It is the list a security review actually wants: what code ran in front of the user. ### Does CentralCSP add a script or latency to my site? No. Detection is built on the Reporting API: browsers generate reports natively and send them in the background, so your pages ship the same bytes as before, plus one response header. There is no agent to compromise, no proxy in your delivery path, and nothing new to add to your own script inventory. ## Find out what your pages ran today. Add the header this afternoon and the inventory builds itself from your next visitors. Free trial, no agent, no proxy, no code change. [Start free trial](https://app.next.centralcsp.com) [Scan your site for free](https://next.centralcsp.com/en/tools/security-headers/) --- Available in: [en](https://next.centralcsp.com/en/platform/supply-chain/), [fr](https://next.centralcsp.com/fr/platform/supply-chain/)