with Gareth Bowker and Katia Kupidonova
Cyberattacks targeting e-commerce payment flows continue to escalate, exposing a critical flaw in how online retailers manage client-side security. Ongoing Magecart campaigns are abusing dynamic hosting, ranging from decentralized blockchain infrastructure to trusted third-party platforms, to inject stealthy skimming code across payment networks. A clear proof point of this evolution is the Magecart campaign uncovered by forensics firm Sansec, where attackers exploited Google Tag Manager and Stripe’s API. The loader retrieved skimmer payloads hidden in attacker-controlled Stripe customer metadata, stole sensitive payment details, and exfiltrated the data back through Stripe’s legitimate channels.
However, malicious actors aren’t the only threat to data privacy; unregulated third-party scripts present an equal risk. A security research report by Jscrambler revealed that ubiquitous marketing tools can exfiltrate sensitive user data right out of the box. Meta and TikTok ad pixels were found methodically harvesting granular checkout data, user identifiers, and commercial intelligence, far beyond standard attribution metrics. In multiple cases, pixel scripts loaded and transmitted customer data before consent management tools could apply user preferences, or even after a user selected “Reject All.”
The Jscrambler’s most recent research study revealed how sensitive customer details, such as loan amounts, credit terms, personal identifiers, and hashed emails, are routinely exposed on non-payment pages long before a user reaches checkout.
Because services like Google Tag Manager, ad pixels, and payment APIs are known and expected, security teams naturally trust them. Without active, client-side script visibility across every script executing in the browser, organizations remain completely oblivious when those legitimate tools are abused or over-collect data.
The Dangers Behind the PCI DSS Gap
When the PCI Security Standards Council updated compliance guidance for SAQ A merchants, it introduced targeted Eligibility Criteria (EC) alongside PCI Council FAQ 1588 and the E-commerce Information Supplement. While these eligibility conditions technically outline similar expectations for managing client-side risk, many merchants overlook the fine print. In practice, smaller merchants skip evaluating the Eligibility Criteria entirely and assume SAQ A gives them a complete pass on client-side script management.
Since those changes were introduced, a troubling trend emerged: smaller merchants are routinely skipping the Eligibility Criteria, leaving massive visibility gaps on their sites. As Gareth Bowker, Head of Security Research at Jscrambler, points out: “When merchants assume those requirements don’t apply, they remove the structure and level of detail needed to identify script attacks. Without those steps, they are left completely blind.”
Understanding which scripts run on a site’s payment pages is essential. “It lets you have an inventory of your scripts so you can validate them and get a notification any time they change,” Bowker explains. “If something changes with one of those scripts, you get an alert, investigate it, detect that something unusual is going on, and respond. Bypassing these controls makes campaigns like the GTM and Stripe skimmer far easier to execute undetected.”
Taking Ownership of Client-Side Security
Relying on payment gateways and third-party scripts does not transfer security or governance responsibility away from the merchant. Client-side security is ultimately a data governance issue: if code executes in your user’s browser, your organization is responsible for the data that script can access, harvest, or transmit.
As Bowker notes: “If a site is using Stripe and Google Tag Manager, chances are they would never detect that type of attack because they are services they know and expect. Even if formal compliance requirements feel relaxed for SAQ A, maintaining strict script inventories and tamper detection remains the single best way to meet basic security objectives.”
When third-party ad pixels over-collect sensitive customer information or skimmers hijack legitimate APIs, it represents a breakdown in client-side data governance. Managing this surface requires clear policies around script authorization, consent enforcement, and real-time behavioral monitoring across the entire web application.
He adds: “The types of attacks we are seeing now are becoming much smarter. They are attacking vectors that static compliance frameworks simply haven’t addressed yet. That is why merchants must look beyond basic compliance lists.”
Going Beyond Checkbox Compliance
Tickbox compliance does not equal safety. Merchants must stop treating PCI DSS as a ceiling for their security posture and take proactive ownership of their digital footprint.
- Implement PCI DSS requirements 6.4.3 and 11.6.1 voluntarily: Even if SAQ A no longer includes these requirements, building a complete script inventory and establishing real-time script-tamper alerts remain baseline defenses against client-side skimmers.
- Look beyond the payment page: Attackers frequently breach non-payment pages, such as login portals, marketing pages, and user dashboards, to hijack sessions or load payloads long before a user reaches checkout. Securing the payment page alone is no longer enough; robust security protections must extend across the entire web application.
- Prepare for sophisticated threats: Threat actors now use LLMs and AI tools to accelerate client-side attacks. Relying solely on third-party payment providers leaves critical gaps that only merchant-side monitoring and integrity management can close.
