PCI DSS 6.4.3 Is the Canary in the Coal Mine for Client-side Security

Here's the hard truth: 98% of websites load third-party scripts. Few teams know exactly what scripts are loaded. Even fewer know what those scripts do (what elements in the browser they are interacting with), and a miniscule amount of teams have any control over what those scripts do. When I say "teams" I'm referring to different stakeholders - security engineers, risk & fraud analysts, compliance managers, and even the marketing department. That's one of the challenges of client-side security. Almost every internal department touches the website. It might be the most collectively edited environment that exists in a company. Marketing wants analytics & tracking on the site, product managers want functionality on web flows, and developers want everything to run smoothly. Every single one of goals opens a door for hackers to siphon data:

• Marketing: Google Tag Manager can be infiltrated to inject malicious scripts through a "trusted" channel. Chatbots and tracking widgets can also be compromised. Go To Market teams need to move quickly but this need for speed can cause unmonitored gaps on the front end

• Product: Adding functionality to web apps means integrating more third-party tools (support tools, dynamic scripts to populate data, integrations to LLM tools). Each vendor is one more link in the software supply chain. A vendor may be compromised...

• Developers: Shipping faster makes it a normal practice to lean on packages and open-source libraries but few teams continuously validate what those dependencies actually load in the browser. Unfortunately, many of those libraries or dependencies can become outdated and exploited by attackers.

Read: What is PCI DSS 6.4.3 & 11.6.1

The Browser Becomes Part of The Compliance Scope

For years, compliance teams could mostly ignore the user’s browser. Liability was fuzzy, and security controls focused on where data was stored and how it moved. That meant databases, servers, and networks.

That model no longer works. Modern websites load code from dozens of external domains (analytics, chat widgets, A/B testing platforms, and advertising networks). Those scripts execute directly in your customers’ browsers, often with access to form fields, payment data, and cookies.

It bears repeating: third-party scripts load code from external domains, but it’s the website owner who puts that code into the user’s browser. If that code is compromised, the site owner should have accountability.

The British Airways and Ticketmaster breaches made this painfully clear. Attackers didn’t breach their servers; they hijacked trusted third-party scripts.

E-skimming, Magecart, and malicious redirects all exploit this same blind spot, targeting consumers visiting websites they believe to be “safe.”

That’s why the PCI DSS 4.0.1 updates drew a line in the sand: the browser is now in scope.

The Early Warning for Every Framework

When a canary stops singing, miners know the air has turned toxic. The PCI SSC as requirements 6.4.3 and 11.6.1 to PCI DSS 4.0.1 is that canary. It’s a warning to every organization that still treats the browser as “outside the perimeter.”

The same currents driving PCI’s update are bubbling elsewhere.

• GDPR already implies front-end responsibility through its data-minimization and consent requirements.

• SOC 2 CC6.6 now calls for continuous monitoring of system components—including the user interface.

• ISO 27001:2022 emphasizes supplier and code-dependency risk.

All of them point to one trajectory: compliance must extend to third-party scripts.

Front-end visibility is becoming as fundamental as network logging once was. In a few years, it won’t just be a PCI requirement but a baseline security hygiene.

Why CSP and SRI Aren’t Enough

Some teams respond to 6.4.3 by deploying a Content Security Policy (CSP) or adding Subresource Integrity (SRI) tags. Those are good steps but not a finish line.

CSP can limit where scripts load from, but it can’t verify what those scripts do once loaded. A single compromised vendor or misconfigured wildcard domain can render it meaningless.

SRI validates static files, but today’s web is dynamic. Scripts update, personalize, and load asynchronously which breaks SRI even when healthy scripts are behaving as intended.

What’s needed now is continuous client-side intelligence: real-time monitoring that monitors JavaScript execution at runtime, alerts when something changes, and proves script integrity across sessions.

When Cookie Banners Aren’t Enough: How PII Leaks Through Third-Party Scripts

Many organizations assume their cookie consent banner or privacy management platform keeps them compliant. It doesn’t. Even when a user rejects tracking cookies, personally identifiable information (PII) can leak through third-party scripts that execute in the browser.

Here’s how it happens: a misconfigured analytics tag, chatbot, or tracking pixel can capture form inputs, email addresses, or session identifiers before a consent framework ever blocks them. Some scripts even transmit this data in real time to external domains bypassing cookie storage entirely. This sensitive data could be sent to say, a server in Russia or China. Security teams might go weeks without noticing if they depend on manual monitoring.

That’s why automated visibility is critical. Without script-level monitoring, these leaks remain invisible to compliance teams. A proper monitoring solution needs to include runtime behavior analysis to fully understand what scripts are doing and which data they have access to.

The Business Case for Client-side Visibility

For some, “client-side security” still sounds like a technical footnote. But compliance failures have become board-level events.

When a hidden script leaks card data, the fines are only the start. You face regulatory penalties, forensic audits, and mandatory customer notifications. Brand trust erodes overnight.

Third-party script monitoring changes that equation.

• Fewer audit findings: You can prove continuous script authorization and change control.

• Fewer incidents: Unauthorized scripts are flagged in minutes, not discovered months later by a regulator.

• Fewer sleepless nights: Compliance stops being reactive paperwork and becomes an engineering process you can observe and automate.

Compliance Engineers, Meet DevSecOps

The old compliance model was static: build controls, file evidence, move on. The new model is dynamic: monitor continuously and respond instantly.

Compliance engineers should think like DevSecOps practitioners. Script versioning and clear governance over what code should and shouldn’t do.

Security practitioners, in turn, need to understand that manual methods like CSP, SRI, or internally built monitoring tooling may no longer meet compliance requirements.

This cultural merge between compliance and engineering is where the next generation of frameworks is headed.

See: Script Inventory and Script Integrity in PCI DSS 6.4.3

What Is PCI DSS 4.0.1?

PCI DSS 4.0.1 is the latest version of the Payment Card Industry Data Security Standard, the global framework that governs how businesses handle, store, and transmit cardholder data. Jointly maintained by the PCI Security Standards Council (PCI SSC), the framework sets technical and procedural safeguards that any entity accepting or processing card payments must follow.

Two requirements in particular reflect this shift:

• Requirement 6.4.3: Mandates that merchants maintain an inventory of all scripts on payment pages, verify their integrity, and ensure they are authorized for use.

• Requirement 11.6.1: Introduces client-side change-detection mechanisms, requiring organizations to detect and alert on unauthorized modifications to payment pages.

Together, these updates make it clear: compliance extends to third-party scripts and client-side pages where customer payment data is actually entered.

The Canary Has Sung

PCI DSS 6.4.3 may read like a small update, but its implications are huge. It’s the first formal recognition that security doesn’t stop at the network edge.