Governance, Risk and Compliance, Compliance Management, Industry Regulations, Security Strategy, Plan, Budget

How visibility into third-party scripts protects vital credit card data  

(Adobe Stock)

COMMENTARY: Millions of organizations have achieved PCI DSS v4 compliance, and many others are in the home stretch as their next assessment date draws nearer.

For merchants, this compliance has become vital, but in today’s digital world, where leaks of third-party scripts and client-side data such as credit card information are on the rise, it’s not the final destination. Companies must take additional steps to ensure full protection.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

The PCI DSS Self-Assessment Questionnaire A (SAQ A) showcases the limits of compliance. In the past, it required all merchants to adopt comprehensive anti-skimming measures, but 2025 brought with it a new SAQ A language that removed requirements 6.4.3 and 11.6.1 for merchants that outsource payment processing to PCI DSS-compliant third-party providers (PSPs).

This new language led many merchants to trust, but not verify, the anti-skimming measures their PSPs have in place. But as many of us know, trust does not make for an effective form of defense.

Just ask merchants using Stripe.

Although Stripe has helped many businesses achieve compliance, in April of last year, we saw evidence that compliance alone was insufficient. Select Stripe merchants were targeted by a digital skimmer called MirrorMask, which, through a change to the merchant’s code, redirected Stripe’s scripts and API calls to a fake Stripe site.

MirrorMask also used a reverse proxy that grabbed and re-routed traffic, spoofed request origins, and displayed checkout pages that “mirrored” the real sites. For customers, everything appeared normal. Yet behind the scenes, attackers were silently harvesting sensitive payment data.

This wasn’t a failure on Stripe's part. It was an industrywide message that client-side security must extend beyond the checkout page to encompass broader data privacy and security measures. Regulations such as HIPAA, DORA, GDPR, and CPRA have increased data privacy awareness. But they ultimately fall short because they do not explicitly mention “client-side” or “web technologies.” 

The industry misconception

When pinpointing the issue, many point fingers at the ease with which teams can add third-party scripts to websites.  Scripts are necessary to deliver an optimal experience, but many businesses go wrong by failing to properly monitor and control third-party scripts, creating prime opportunities for data exfiltration and content manipulation. 

Attackers can use third-party scripts to gain entry and from there, capture inputs, manipulate Document Object Model (DOM) elements, clone user interfaces, and leak data without detection. Behavioral tags and tracking pixels often leak personal information, creating a compliance gray area that regulators are increasingly watching more closely.

Whatever the culprit, the impact has multiple layers. It start with the theft of information, followed by regulatory compliance violations, and then an erosion in customer trust.

In closing the gap between compliance and actual security, merchants must gain real-time visibility into every script running on their website. That means managing third-party script behavior, obfuscating and protecting first-party code, and monitoring for unauthorized changes across all web pages. The browser represents a vital piece of infrastructure and we must regulate it as such.

PCI DSS v4 remains a good starting point, especially two specific requirements, 6.4.3 and 11.6.1. These address script monitoring and skimming defenses. Regulations such as CPRA and HIPAA should look to these two requirements as a guide for how they can expand their data privacy and security guidance with client-side technologies. 

Why client-side security, and why now

Regulations such as CPRA already require businesses to employ reasonable security procedures when handling personal information. While they may not specifically call out the client side, the implications are clear, and it’s only a matter of time before the point gets made more explicit. That’s because a third-party script accessing unencrypted PII would represent a clear compliance violation that could result in significant legal action.

Client-side security can close the visibility gap and enforce controls directly inside the browser to prevent unauthorized behaviors, block data leaks, and produce audit trails that support compliance not just with PCI DSS, but with broader frameworks like CPRA and GDPR.

Customer trust, privacy obligations, and regulatory risk all converge on the client-side. Yet, it’s also where most organizations lack visibility. Businesses that lead in client-side security are not taking a wait-and-see approach. They go beyond checkbox compliance to gain customer trust, data integrity, and long-term resilience.

Rui Ribeiro, co-founder and CEO, Jscrambler

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.

You can skip this ad in 5 seconds