BARR Advisory Senior Consultant Kyle Kofsky joined cside CEO Simon Wijckmans earlier this week for a live discussion on how to streamline compliance with the Payment Card Industry Data Security Standard (PCI DSS).
During their talk, Kofsky and Wijckmans gave an in-depth overview of requirements 6.4.3 and 11.6.1, sharing unique insights and offering tips and tricks for complying with the pair of rules, which were created to address the rising threat of client-side attacks in e-commerce.
Client-Side Attacks on the Rise
“E-commerce skimming is becoming increasingly common,” Kofsky said.
“This is really for two reasons,” he explained. “The first being that the attacker does not need access to the back-end infrastructure or servers.”
The second, he said, is that these sorts of attacks are particularly difficult to detect. “There’s really no functional or cosmetic changes to the payment pages. The threat actor just needs access to the payment page from their browser to handle script injection, which is going to effectively hijack customer browser sessions when they’re interacting with those payment pages.”
According to Wijckmans, cside detected 380,000 client-side attacks in the first half of 2025 alone. These attacks “can cover a lot of different domains, because we all use the same third-party scripts,” he said. “That then impacts hundreds of thousands of websites sometimes at once.”
It’s a threat that Kofsky says is growing as the e-commerce industry evolves. “As e-commerce platforms become more and more complex, businesses are going to become more and more reliant on external scripts, which just exposes them to additional risk of compromise,” he said. Requirements 6.4.3 and 11.6.1 were introduced to mitigate this risk.
Breaking Down Requirements 6.4.3 and 11.6.1
6.4.3 covers payment page scripts, requiring organizations to ensure each script is authorized, confirm each script’s ongoing integrity, and maintain an inventory of scripts that includes a written justification for each script’s use.
The PCI Security Standards Council (PCI SSC) uses this language to describe the requirement:
“All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
- A method is implemented to confirm that eachscript is authorized.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.”
The PCI SSC also defines testing procedures for requirement 6.4.3:
- “6.4.3.a Examine policies and procedures to verify that processes are defined for managing all payment page scripts that are loaded and executed in the consumer’s browser, in accordance with all elements specified in this requirement.
- 6.4.3.b Interview responsible personnel and examine inventory records and system configurations to verify that all payment page scripts that are loaded and executed in the consumer’s browser are managed in accordance with all elements specified in this requirement.”
The language is relatively vague, Kofsky said in Tuesday’s webinar. “It does not specify how this authorization has to occur, who does it, how it’s done, or whether the process is manual or automated,” he said. “What’s important is that there is explicit approval of these scripts being used on the payment pages.”
PCI DSS also “does not mandate a specific mechanism for assuring script and payment page integrity,” Kofsky noted, so long as “the organization ensures that their payment page does not contain unauthorized or malicious content.”
11.6.1 requires organizations to deploy a change- and tamper-detection mechanism to mitigate the risk of unauthorized modifications to payment page scripts and security-impacting HTTP headers.
Here’s the exact language used in PCI DSS 4.0.1:
“A change- and tamper-detection mechanism is deployed as follows:
- To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
- The mechanism is configured to evaluate the received HTTP headers and payment pages.
- The mechanism functions are performed as follows:
- At least weekly
OR - Periodically (at the frequency defined in the entity’s targeted risk analysis).”
- At least weekly
“The whole reason why you’re expected to monitor that is because if there are changes to [headers], suddenly that can be an indicator of compromise,” Wijckmans said. “If you’re only checking the script URLs but not the actual contents, you’re not complying with 11.6.1.”
The Importance of a Multi-Pronged Approach to Security
Wijckmans noted that one key purpose of these requirements is to prevent unauthorized scripts from loading. Purely using a crawler cannot stop a script from loading, which is why he recommends a multi-pronged approach to security.
“A client-side attack is dynamic,” he said. “You cannot approach a dynamic attack with a static analysis tool. A static analysis tool is not going to be able to detect an attack.” For instance, bad actors can recognize crawlers’ IP addresses to serve them clean pages, while still delivering malicious code to other users.
“Traditional internal security measures alone are not enough to prevent these attacks,” Kofsky said. “Nothing is really occurring on the back-end that’s going to be picked up by those normal security measures.”
“The closest you can get to 99% coverage is by combining” approaches, Wijckmans said. This is why cside’s platform combines four defense mechanisms:
- Client-side monitoring, to monitor scripts in real-time and flag malicious activity;
- Periodic crawler scans;
- Script inspection; and,
- Selecting high-risk scripts to proxy for maximum security.
With these features as well as change detection and alerts, security header monitoring, and AI-assisted documentation preparation for script approvals and justifications, cside’s dashboard automates 6.4.3 and 11.6.1 compliance requirements.
Path to Compliance
For organizations that must comply with 6.4.3 and 11.6.1, the time it will take to prepare varies widely based on your current understanding of your payment page scripts, how many scripts you have, and how much time and flexibility your team has to implement solutions.
Working with a qualified security assessor (QSA) firm like BARR Advisory to complete a readiness assessment before your PCI DSS audit can help organizations gauge where they are in the process and understand the lift required to achieve compliance with these new requirements.
Contact us today to learn how BARR Advisory can simplify your path to PCI DSS compliance.
To hear the full discussion, watch the webinar now on-demand.