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.

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 Book a 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.

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
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
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

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.

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.
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.
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.

my-store.com/checkout

Scripts seen in live traffic

Script	Status	Last seen	CVE
js.stripe.com/v3	Justified	2 min ago	–
jquery-3.4.1.min.js	Justified	1 min ago	CVE-2020-11023
analytics.js	Justified	5 min ago	–
pixel-track.js	New script	Just now	–

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.

Built from production reports
Exfiltration destinations locked down
Report-only first, enforce when clean

See the CSP builder

SRI hashes generated in seconds
Integrity violations reported live
Covers the polyfill.io failure mode

Generate SRI hashes

CSP and header scanning
Reporting setup verified
Free, no account needed

Scan your 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.

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

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.

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 Scan your site for free

Every script your visitors run, and what's inside it.

The breach that never touches your server.

Polyfill.io, 2024

British Airways, 2018

npm chalk and debug, 2025

One response header in. Every script accounted for.

Browsers report every script they run

We identify what's inside each script

Changes and CVEs become alerts