PCI DSS 6.4.3 and 11.6.1: A Deep Dive into Payment Page Security and Integrity Requirements

For organizations that process payment card data online, the payment page has become one of the most targeted points of attack. Modern e-commerce environments rely heavily on third-party scripts, embedded payment forms, and dynamic content—all of which expand the attack surface in ways that can be difficult to monitor.

At the same time, client-side attacks—particularly e-skimming and malicious script injection—have surged. Attackers are no longer trying to break into backend systems first. Instead, they target the browser, where payment data is entered in real time. This is why PCI DSS has introduced requirements 6.4.3 and 11.6.1.

These controls are designed to ensure that organizations understand, manage, and continuously monitor what’s happening on their payment pages, especially when it comes to scripts. Here are the most important things to know:

• You must be aware of and control every script running on your payment page, including third-party and dynamically loaded scripts.
• Content Security Policy (CSP) and Subresource Integrity (SRI) are key mechanisms for restricting and validating what loads in the browser—but they are not sufficient on their own.
• Continuous, real-time monitoring is essential to detect unauthorized changes and maintain compliance with PCI DSS requirements 6.4.3 and 11.6.1.

Let’s dive deeper.

Why PCI DSS Introduced These Requirements

Client-side attacks are now one of the most common ways attackers steal payment card data. In fact, attackers often inject malicious JavaScript into legitimate websites to skim cardholder data directly from the browser. These attacks can impact thousands of websites at once because many organizations rely on the same third-party scripts. Rather than using stolen cards themselves, attackers typically sell this data on the dark web—making large-scale attacks extremely profitable.

This growing threat landscape led PCI DSS to introduce requirements 6.4.3 and 11.6.1, with a clear goal: Ensure that payment pages are free from unauthorized or malicious scripts.

Understanding Payment Pages vs. Payment Forms

Before diving into the requirements, it’s important to clarify scope. A “payment page” is the full webpage where a transaction occurs. A “payment form” is the specific embedded element that collects cardholder data.

This distinction matters for compliance. If your entire payment page is fully outsourced or redirected, you may not need to worry about these requirements. If you embed a payment form (e.g., via iFrame), you may still be responsible. If you host or control the payment form, you are definitely in scope.

Organizations completing SAQ A-EP or SAQ D will be required to fully implement and validate requirements 6.4.3 and 11.6.1.

PCI DSS Requirement 6.4.3

Requirement 6.4.3 focuses on script authorization and management. At its core, this requirement expects organizations to:

• Maintain an inventory of all scripts on the payment page
• Ensure scripts are authorized before they are loaded
• Justify why each script is necessary

However, the standard leaves room for interpretation.

“The standard is a little vague—it does not specify how this authorization has to occur, who does it, or whether the process is manual or automated,” Kyle Kofsky, senior consultant and Lead QSA at BARR Advisory, said.

What matters most is the outcome. You must be able to demonstrate that only authorized scripts are running on your payment page.

Many organizations don’t know how many scripts are actually running on their site, especially when third-party vendors dynamically load additional resources. Even maintaining a simple list of scripts can go a long way toward meeting compliance expectations, but inventory alone is not enough. If you allow a script without understanding what it does—or what it might load—you are still at risk.

PCI DSS Requirement 11.6.1

Requirement 11.6.1 builds on 6.4.3 by focusing on change detection and integrity monitoring. This means organizations must:

• Detect unauthorized changes to scripts or page content
• Identify when new scripts are introduced
• Monitor for malicious behavior in real time

This is where many organizations struggle. Traditional tools like scanners or crawlers are not effective here. Attackers can serve malicious scripts selectively—only to real users, not to scanning tools. This allows them to bypass periodic scans entirely. 

Attackers can also inject scripts for short time windows, target specific users or geographies, or deliver different content based on user behavior. Because of this, PCI DSS expects ongoing, real-time visibility into what’s happening in the browser.

Key Security Mechanisms: CSP and SRI

Two commonly referenced controls for securing payment pages are Content Security Policy (CSP) and Subresource Integrity (SRI).

A CSP is a browser security mechanism that restricts which sources are allowed to load content (such as scripts, styles, or images). For example, CSP can:

• Block unauthorized domains from loading scripts
• Reduce the risk of cross-site scripting (XSS) attacks
• Enforce allowlists for trusted resources

However, CSP has limitations. If a trusted third-party script is compromised, CSP will still allow it to run. Additionally, CSP policies themselves must be monitored—because changes to the policy can introduce risk.

SRI ensures that a script has not been modified by validating it against a known cryptographic hash. When a browser loads a script with SRI, it calculates the script’s hash, compares it to the expected value, and blocks execution if the values don’t match. This helps detect tampering, but only for static scripts. If a script changes frequently or is dynamically generated, SRI becomes harder to maintain.

While both CSP and SRI are valuable, neither fully addresses the problem. CSP controls where scripts come from, not what they do, and SRI validates script integrity, but not behavior. Neither provides real-time monitoring of script activity. That’s why a layered approach is recommended.

SAQ A Eligibility and the Cost of Noncompliance

Recent PCI DSS updates removed these requirements from SAQ A, but there’s a catch. To qualify for SAQ A, merchants must confirm that their site is not susceptible to script-based attacks. In practice, that’s a difficult claim to make.

Organizations should be cautious about relying on eligibility criteria to avoid these requirements. If you are embedding any payment functionality, you may still be exposed.

Failing to meet these requirements can have serious consequences, including:

• Fines from acquiring banks (ranging from thousands to hundreds of thousands of dollars)
• Loss of ability to process payments
• Failed assessments and additional audit costs
• Loss of customer trust and contracts

“When your next assessment comes around, or if it’s your first assessment coming up, you have to be compliant with these requirements,” Kofsky said.

The Bottom Line

Client-side attacks are now one of the most significant threats to payment security—and PCI DSS requirements 6.4.3 and 11.6.1 are designed to address that reality.

For many organizations, especially smaller teams, these requirements can feel overwhelming. Understanding what scripts are running, controlling them, and monitoring them continuously is not a trivial task. But the responsibility ultimately lies with the organization. Whether you build in-house controls or leverage a third-party platform, the key is being able to clearly demonstrate to your assessor that:

• You know what’s running on your payment page
• You control what is allowed to run
• You can detect and respond to unauthorized changes

These elements are the foundation of modern credit card compliance—and they’re only becoming more important as attackers up their game.

Need help preparing for PCI DSS requirements 6.4.3 and 11.6.1 or evaluating your current approach to compliance? Contact us today for a free consultation.