--- title: "Client-side supply chain & Magecart script monitoring" description: "Magecart and supply-chain protection: inventory every script real browsers run, its version and CVEs, and get alerted when one changes. No agent, no proxy." url: "https://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.centralcsp.com) [Book a demo](https://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. A client-side supply-chain attack compromises a third-party script your page already loads, so the malicious code runs in your visitors' browsers rather than on your servers. Server-side tooling misses it because nothing on your infrastructure changed. Our annual census found 22.0% of the web ships a Content-Security-Policy at all, and only 0.97% of domains have one that passes. 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. 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 fourth-party scripts your third parties load after they run, like the tag your tag manager pulled in 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. ### A third-party script 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 - Fourth-party scripts: the ones your third parties load after they run - 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 report both by name. A script that stops matching its SRI hash arrives as an integrity-violation report; a script whose bytes changed arrives as a csp-hash script hash report; a page talking to an undeclared origin arrives as a connection report. - Outbound connections to unknown origins reported - SRI mismatches arrive as integrity-violation reports - Byte changes arrive as csp-hash script hash reports 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://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://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://centralcsp.com/en/tools/security-headers/) Approaches ## Three ways to watch your scripts. Three deployment models, by the names buyers use: agentless reporting, an injected agent, and proxy delivery. 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 (agentless) | Injected agent | Proxy delivery | | --- | --- | --- | --- | | Adds nothing to your page | Nothing, a header | Its own script | A proxy in the path | | Sees real visitor sessions | Every browser reports | While its script runs | Proxied traffic only | | Catches cloaked skimmers | Fires on real checkouts | Unless evaded first | If payload inspected | | Produces PCI DSS 6.4.3 evidence | Exportable inventory and justifications | Varies by product | Varies by product | | Blocks malicious scripts inline | Via your CSP | In-browser blocking | Blocks at the edge | | Adds no page weight or latency | Zero bytes added | Runs on every page | Latency per fetch | | Adds no new attack surface | Never in the page | One more third party | 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 Pricing ## CVE detection starts on Scale. The script inventory is included from the Start plan, and alerting, automated scanning and the full API and MCP arrive with Business. Scale adds CVE detection, alongside payment page evidence for PCI DSS. - Script inventory from real traffic - CVE and end-of-life detection - New-script and hash-change alerts - API, MCP and CSV exports ### Scale PCI DSS v4 evidence, at portfolio scale. €349.99 / mo - Applications 30 - Users 100 - Reports / month 10,000,000 Everything in Business, plus: - CVE detection - Payment page monitoring - PCI DSS evidence - SSO and audit log - Invoicing and procurement support [Get started](https://app.centralcsp.com/?plan=scale&billing=monthly) ## 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://centralcsp.com/en/platform/pci-dss/) - Script inventory with justifications - Change and tamper alerts - CSV and PDF evidence exports - SBOM for the assessor Further reading ## How client-side attacks actually work Where skimmers come from, how a script inventory is built, and how to enforce integrity on every asset. - [Script hash reports](https://centralcsp.com/en/docs/web-security/reporting-api/reports/csp-hash) - [How to detect a client-side skimmer](https://centralcsp.com/en/blog/magecart-formjacking-detection) - [Build a script inventory with CSP hash reporting](https://centralcsp.com/en/blog/script-inventory) - [Enforce SRI on every script with Integrity-Policy](https://centralcsp.com/en/blog/integrity-policy-explained) - [How attackers abuse Google Tag Manager](https://centralcsp.com/en/blog/google-tag-manager-security-risk) - [CSP and PCI DSS v4: 6.4.3 and 11.6.1](https://centralcsp.com/en/blog/csp-pci-dss-v4) FAQ ## Frequently asked questions Client-side supply-chain attacks and how we catch them, answered. ### What is Magecart, and is it the same as formjacking or e-skimming? Magecart is the name given to the family of attacks that inject skimming JavaScript into checkout and login pages to steal card numbers and credentials as they are typed. Formjacking, e-skimming and web skimming describe the same technique under different names. The defining trait is where it runs: the theft happens in the visitor's browser, in the page you served, which is why your server logs and your database look untouched afterwards. The British Airways breach on this page is the textbook case. ### 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. ### Is Subresource Integrity enough on its own? It is a real control, and it is not sufficient. SRI pins a file whose markup you control: you put the hash in the tag, and the browser refuses the file if the bytes ever differ. That covers a swapped library on a CDN. It cannot cover a script injected at runtime by a tag manager, or one loaded by another script, because neither has a tag you wrote a hash into. That gap is why the browser also reports integrity violations and script hash changes: SRI tells you a pinned file was swapped, and the hash reports tell you about everything that was never pinned in the first place. ### 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. ### How quickly will I know a script changed? As reports arrive from live traffic. Browsers queue reports and deliver them out of band, typically within a minute of the page load that produced them, so a new script, a changed hash or a new outbound origin surfaces once real visitors have loaded the page. The alert rule fires on that event, not on a schedule. The contrast worth drawing is with crawler-based checks, which tell you at the cadence you set them to run: PCI DSS 11.6.1 puts the floor at once every seven days, and a weekly crawl meets that floor while leaving six days in which a skimmer is live and unreported. ### 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.centralcsp.com) [Scan your site for free](https://centralcsp.com/en/tools/security-headers/) --- Available in: [en](https://centralcsp.com/en/platform/supply-chain/), [fr](https://centralcsp.com/fr/platform/supply-chain/)