If you run a checkout page and you’re getting assessed in 2026, the grace period is over. PCI DSS requirements 6.4.3 and 11.6.1 became mandatory on April 1, 2025. That means this year is the first time a QSA is looking at a full assessment cycle and expecting to see roughly a year of continuous evidence behind your payment-page scripts — not a screenshot you took the week before the audit.
That single change is why “best PCI DSS 6.4.3 tool” has turned into a real buying decision instead of a checkbox. You can’t fake twelve months of script monitoring after the fact. So the question stops being “do I need a client-side security tool” and becomes “which one, and is the one bundled with my CDN actually good enough.”
I’ll walk through what the two requirements actually demand, why CSP by itself doesn’t get you there, and how the main tools — cside, Feroot, Jscrambler, Akamai, Cloudflare, and Imperva — really differ once you look past the marketing. There’s also a free-ish path at the end for small merchants, and an honest note on where it falls apart.
What 6.4.3 and 11.6.1 actually ask for
These two requirements are often lumped together, but they’re doing different jobs.
6.4.3 is about scripts on your payment page. You need an inventory of every script that loads in the customer’s browser on that page, a written justification for why each one is there, and a way to confirm each script’s integrity — that it hasn’t been tampered with. Three verbs: inventory, authorize, assure integrity.
11.6.1 is the detection half. You have to detect and alert on unauthorized changes to the payment page — both the scripts and the security-relevant HTTP headers (think Content-Security-Policy itself). The standard says this check runs at least weekly, though in practice “weekly polling” is a weak interpretation and most tools watch continuously.
The intent behind both is Magecart-style skimming. An attacker compromises a third-party script — an analytics tag, a chat widget, a CDN-hosted library — and quietly injects code that reads the card fields and ships them off to a server you’ve never heard of. The customer sees nothing. You see nothing, until the chargebacks roll in. 6.4.3 is supposed to make you notice the new script; 11.6.1 is supposed to make you notice when an approved one changes.
Why CSP alone doesn’t cut it
The cheap instinct is “I’ll just add a Content-Security-Policy header and call it done.” CSP is genuinely useful and you should have one. But it solves a narrower problem than 6.4.3 implies.
A CSP is an allow-list of domains. It tells the browser “only load scripts from these origins, block the rest.” That stops a script from an obviously out-of-scope host. What it does not do is look at the JavaScript. If an attacker compromises a script that’s already on an approved CDN — exactly what happened in the Polyfill.io supply-chain attack, where a trusted, allow-listed domain started serving malware — your CSP waves it right through. The origin is on the list, so the browser runs it.
That’s the gap. 6.4.3 wants integrity assurance, not just origin control. CSP gives you origin control. You need something that notices the content changed, or at least that a known-good hash no longer matches. Which is where Subresource Integrity and the dedicated tools come in.
The tools, and how they actually differ
The vendors all claim “PCI 6.4.3 and 11.6.1 compliance,” so that line tells you nothing. What separates them is how they see your scripts. There are basically three architectures, and the architecture determines what an attacker can hide from.
CDN/header-based: Cloudflare and Akamai
Cloudflare’s Page Shield (rebranded to Client-Side Security in 2026) and Akamai’s Page Integrity Manager sit at the edge. If you already run your traffic through one of these CDNs, the appeal is obvious: no new script tag, no extra vendor, it’s a toggle on infrastructure you already pay for.
The mechanics matter, though. Page Shield leans heavily on CSP plus a crawler that fetches scripts after page load and checks sources against known-bad patterns. It’s monitoring, and it’ll satisfy chunks of 6.4.3, but a crawler that fetches the script separately from a real user session can be fooled — an attacker can serve clean code to the crawler and skimmer code to actual shoppers. That’s the cloaking problem, and any tool that inspects scripts out-of-band rather than in the real session is exposed to it.
Akamai’s Page Integrity Manager is more behavior-focused — it watches what scripts do in the browser rather than just where they came from, which is a stronger model than pure CSP. Both are reasonable if you’re already deep in that CDN’s ecosystem and want one less contract. Pricing is the usual enterprise story: bundled into higher-tier plans, not transparently listed, talk-to-sales.
Agent-based in the browser: Feroot, Imperva
Feroot’s PaymentGuard (and PageGuard) runs monitoring code inside the browser and enforces an allow-list of approved scripts and permissions. Feroot also offers an Inspector that uses synthetic sessions to simulate users. The strength is deep visibility into permissions and data access. The documented weakness is the same cloaking issue: synthetic/crawler-style sessions can be served different code than real users, and an agent running in the browser is operating in the same environment as the attacker, so sophisticated skimmers can try to detect and bypass it.
Feroot is a serious compliance-automation product and a lot of teams are happy with it. The friction points worth knowing up front: there’s no free or self-service tier, and you’re scheduling a demo before you can really evaluate it. Imperva sits in a similar enterprise bucket — strong if you’re already buying their WAF and app-security suite, sold the same way.
Server-side analysis of real sessions: cside
cside’s pitch is the architectural answer to cloaking. Instead of only checking origins or running a crawler, it downloads every script from real user sessions to its own infrastructure and analyzes the actual code server-side, in real time. The argument is that a bad actor can’t serve cside clean code the way they can fool a crawler, because cside is riding along in genuine traffic, not knocking on the door separately.
Whether that’s worth switching for depends on your threat model, but the reasoning is sound, and it’s the one design that directly closes the “clean code for the scanner, dirty code for the customer” hole. cside is also notably the only one of these with fully public developer docs and API references you can read without a sales call — which, if you’ve ever tried to scope a compliance tool, is a bigger deal than it sounds.
Jscrambler
Jscrambler is a slightly different animal. Its core has always been JavaScript obfuscation — protecting your own first-party code from reverse-engineering. The Webpage Integrity module bolts on client-side monitoring with code locks that restrict when and where scripts run. If you also care about protecting proprietary front-end logic, the combined story is appealing. If all you need is 6.4.3/11.6.1, you’re paying for capability you won’t use.
Quick comparison
| Tool | Model | Sees actual served code? | Real-user vs sampled | Pricing transparency | Best when |
|---|---|---|---|---|---|
| Cloudflare Client-Side Security | CDN + CSP + crawler | Partly (out-of-band) | Crawler/sampled | Bundled, opaque | Already on Cloudflare Enterprise |
| Akamai Page Integrity Manager | CDN + behavioral | Behavioral signals | Real-user behavior | Bundled, opaque | Already on Akamai |
| Feroot PaymentGuard | Browser agent + synthetic | Limited (synthetic sessions) | Synthetic + real | Demo-gated, no free tier | Want compliance automation, enterprise budget |
| Imperva | Agent + suite | Limited | Mixed | Demo-gated | Already buying Imperva WAF |
| Jscrambler | Obfuscation + integrity | Yes for locked code | Real-user | Demo-gated | Also protecting first-party JS |
| cside | Server-side analysis of real sessions | Yes | Real-user | Public docs, self-serve-ish | Want anti-cloaking + transparent eval |
Take the “sees actual served code” column with the usual caution — vendors describe their own coverage generously, and your QSA cares about evidence, not architecture diagrams. But it’s the column that actually maps to the Polyfill.io failure mode, so it’s the one I’d weight most.
How to choose, by stack
If you use Stripe or a fully hosted/iframe checkout: your scope might be smaller than you think. When the card fields live entirely inside a PSP-hosted iframe, the scripts on your page have less direct access to cardholder data, which can push you toward SAQ A and a lighter 6.4.3 burden. Confirm this with your QSA before you assume it — the SAQ A eligibility rules around embedded payment pages got stricter, and “I use Stripe” is not automatically a free pass. But if you qualify, you may not need a heavyweight tool at all.
If you built your own payment page (SAQ D territory): you own all the scripts and all the risk. This is where a real client-side tool earns its cost. Weigh anti-cloaking design heavily here, because a self-built page is exactly the kind of target where serve-clean-to-the-scanner attacks pay off.
If you already run Cloudflare or Akamai Enterprise: start by switching on what you already have and see whether it produces evidence your QSA accepts. The marginal cost is near zero. If your assessor pushes back on crawler-based coverage, then look at a code-inspecting tool. Don’t buy a second vendor before you’ve tested the one you’re already paying for.
If you’re greenfield with no CDN lock-in: evaluate on architecture and transparency. The tools you can actually trial without a three-week sales cycle will save you real time, and the anti-cloaking design is the part that determines whether you’re buying protection or buying a compliance fig leaf.
The free-ish path, and where it breaks
You can get a long way toward 6.4.3 and 11.6.1 without buying anything. It’s more work and it has real limits, but for a small merchant on a tight budget it’s a legitimate starting point.
The recipe is CSP + SRI + a manual inventory. Maintain a spreadsheet (or a small JSON file in your repo) listing every script on the payment page, its source, and a one-line business justification — that’s your 6.4.3 inventory and authorization. Add Subresource Integrity hashes to every <script> tag you can, so the browser refuses to run a script whose content no longer matches the hash you approved — that’s a real integrity control. Ship a strict CSP with report-uri/report-to so violations get logged. For 11.6.1, a scheduled job that diffs the rendered page’s scripts and headers against your approved manifest, weekly or better, and alerts on any change.
Here’s where it breaks down. SRI only works on scripts with a fixed URL and stable content — it falls apart the moment a third-party tag (analytics, a tag manager, an A/B testing tool) loads dynamically or rotates its code, which is most of the interesting ones. CSP, as covered above, won’t catch a compromise on an allow-listed origin. And the whole thing is maintenance you own forever: every new tag, every vendor update, every marketing pixel someone adds without telling you breaks the manifest and either blocks something legitimate or silently stops protecting you.
The free path is fine when your payment page has a handful of static, first-party scripts and you control all of them. The minute marketing wants a dynamic tag manager on the checkout, you’ve outgrown it. And remember the 2026 reality: the QSA wants continuous evidence over time, not a point-in-time config. A manual process that nobody runs after month two produces exactly the gap an assessor is trained to find.
If you’ve been putting this off, the cheapest useful first move isn’t picking a vendor — it’s opening your payment page in dev tools and writing down every script that loads. Half the teams I’ve talked to are surprised by what’s actually on there. That list is your inventory, your scope, and your honest starting point for everything above.
Sources:
- How to Comply with PCI DSS 4.0 Requirements 6.4.3 and 11.6.1 — Imperva
- PCI Requirements 6.4.3 & 11.6.1 Explained — DataDome
- Script Security: Achieving PCI DSS v4 Compliance Before the Deadline — Akamai
- PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 — Feroot
- Client-Side Security Tools to Comply with PCI 6.4.3 & 11.6.1 — Jscrambler
- Best Client-Side Script Security Solution 2026 — cside