- Most payment-page attacks now live in JavaScript the customer’s browser executes — not in your origin server.
- PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 expect an inventory, authorization, and integrity check of those scripts.
- A quarterly file review is not the same as watching what actually runs at checkout.
For years, security teams treated the checkout as a backend problem: tokenize the card, lock down the payment processor, pass the ASV scan. That model still matters. It is no longer enough.
The attacker’s cheapest path to PAN is often a script that loads on the page the shopper already trusts. Tag managers, A/B testing tools, chat widgets, analytics pixels — each one is a live code path in the browser. If any of them is compromised, the form fields that collect card data can be read before they ever reach your servers.
The perimeter did not disappear. It moved into a tab the customer already opened.
How modern skimming actually works
Classic Magecart campaigns still exist: inject a snippet into a Magento theme, harvest cards, exfiltrate to a lookalike domain. The newer pattern is quieter. A supply-chain change in a third-party CDN, a forgotten staging tag that went live, or a marketing pixel that started loading from a new host overnight.

From the shopper’s point of view, nothing looks wrong. The padlock is there. The brand is familiar. The form submits. The only difference is that a listener copied the card number to an endpoint you do not own.
What PCI DSS 4.0.1 now expects
Requirement 6.4.3 asks you to manage payment-page scripts: inventory them, justify them, and ensure they are authorized. Requirement 11.6.1 asks you to detect unauthorized changes to those pages and the HTTP headers that protect them — frequently enough that a weekly change would not slip through unnoticed.
- Know every script that can run on payment pages, including ones injected by tag managers.
- Authorize each one against a business purpose, not against “it has always been there.”
- Watch integrity over time so a silent host or hash change is an alert, not a footnote in next quarter’s audit.
What good looks like in practice
Client-side security is not a one-time content-security-policy paste. CSP helps. Subresource Integrity helps. Neither tells you what a tag manager decided to load at 2 a.m., or whether a previously allowed script started posting to a new collector.
Teams that stay ahead treat payment pages like production infrastructure: an inventory, a change window, and a monitor that compares what should run with what actually ran.
Start this week
You do not need a full program on day one. You need a truthful map of checkout scripts, an owner for each one, and a way to notice when the map is wrong. The rest of the control set — CSP, SRI, change detection — is much easier once that map exists.
Keep going
Want this as a working program?
This article is a point of view. If you want to see how teams run it in practice, talk with us.
Talk to our team
