Dedicated Client-Side Security Tools to Comply with PCI DSS Requirements 6.4.3 and 11.6.1

As the payment landscape evolves, compliance with PCI DSS v4 (v4.0.1 is the latest) is now a reality, with the deadline to adopt the future-dated requirements behind us. It is a critical defense against growing web skimming attacks (also known as e-skimming and digital skimming) and data leakage risks.

Two of the standards’ updated requirements, PCI DSS 6.4.3 and 11.6.1, draw a clear line under what’s expected of online merchants and payment service providers: improved change- and tamper-detection capabilities for payment pages.

Under 6.4.3, every script loaded in the consumer’s browser must be catalogued, justified with a business or technical reason, and validated for integrity. At the same time, PCI 11.6.1 mandates a mechanism to detect unauthorized modifications, from header changes to script content alterations, ensuring any suspicious activity triggers alerts. Together, these requirements reinforce PCI DSS compliance as an ongoing, proactive stance against client-side risks such as sensitive data leaks rather than a one-time assessment milestone. 

In this article, let's break down requirements 6.4.3 and 11.6.1 and present an overview of the most effective tools or methods available on the market for detecting e-skimming activities to meet PCI DSS v4 requirements and keep web skimmers at bay. 

Requirement 6.4.3 Explained

The PCI DSS requirement 6.4.3 calls for businesses to maintain assurance, or in other words, strict oversight, of every script that executes in the customer’s browser on a payment page.

To meet this requirement, organizations must approve each script, verify that it hasn’t been altered, and maintain an up-to-date catalogue that explains the business or technical justification for its presence.

The expectation extends beyond internally developed code to all external and third-party scripts, ensuring that no unvetted or unexpected components are introduced into the payment flow. By strengthening script visibility and accountability, this requirement helps protect against client-side threats such as web skimming and malicious injections that aim to tamper with the checkout experience.

PCI DSS 4 Requirement 6.4.3 Summary 

The goal of requirement 6.4.3 is to prevent data leakage and e-skimming of cardholder data.

• Authorization: A method is implemented to confirm that each script is authorized.

• Integrity: A method is implemented to ensure the integrity of each script.

• Inventory: An inventory of all scripts is maintained, with a written justification as to why each script is necessary.

Requirement 11.6.1 Explained

The PCI DSS requirement 11.6.1 focuses on actively monitoring and detecting unauthorized changes to critical components of payment pages. This requirement mandates that organizations implement mechanisms to identify any alterations to scripts and headers that could indicate tampering or malicious activity. Alerts must be generated when such modifications are detected, allowing rapid investigation and response.

PCI DSS 11.6.1. Summary 

The goal of 11.6.1 is to ensure that client-side attacks, including script injections or web skimming attempts, are identified to prevent the compromise of payment data, reinforcing the security of the overall payment environment.

• Alerting: Any solution must be able to alert personnel when any of the defined behaviors are encountered.

• Headers: A mechanism must be able to detect unauthorized modifications to security-impacting headers.

• Script Content Changes: A mechanism must be able to detect changes to the script contents on the payment page.

• Cadence: A mechanism must be configured to run either weekly or at a cadence defined by a targeted risk analysis.

Relevant Adjustments in PCI DSS version 4.0.1

The PCI Security Standards Council’s PCI DSS 4.0.1 is a limited revision that introduces no new requirements but clarifies and reframes certain existing ones, especially PCI DSS Requirements 6.4.3 and 11.6.1. 

Under 6.4.3, the definition of “necessary” scripts on a payment page shifts from “functionality required to accept a payment” to requiring a documented business or technical justification for every script — making the condition normative, not optional. 

For 11.6.1, the standard now explicitly focuses on detecting only “security-impacting” changes to HTTP headers or script contents, and clarifies that monitoring should occur on a “weekly” cadence rather than “at least once every seven days.”

Organizations That Need to Comply with PCI DSS v4

Is PCI DSS compliance mandatory by law for all merchants that accept online payments? 

The PCI Security Standards Council (PCI SSC) states that the “Council is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council, American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.” 

There is no law, but there can be repercussions for non-compliance and any consequences of leaked sensitive data, payment data, and breaches. Generally, any organization that processes, stores, or transmits payment card data must comply with the standard. 

Below are the main organizations that can be grouped in the following way: 

Merchants

Organizations that accept payment cards. This includes any organization that accepts online payments for goods and services, regardless of size, ranging from small online retailers to large e-commerce websites. 

Payment Service Providers (PSPs)

Third-party organizations that handle payment card data on behalf of merchants or other service providers, including, for example, payment processors and payment gateways.

Financial Institutions

Issuers and acquiring banks, and other financial institutions in the payment card ecosystem have to comply with requirements related to PCI DSS v4.

Teams Responsible for PCI DSS Compliance in Your Organization

When exploring PCI compliance solutions, it’s important to consider the different teams and roles within your organization that will be involved in evaluating, managing, and using them. 

Key stakeholders

PCI Compliance Manager, Internal Security Assessor (ISA), or Information Security Risk & Compliance Manager, usually within the compliance team, must ensure that all PCI DSS-related documentation, script approvals, and assessment preparation meet the PCI standards.

Security teams with a Chief Information Security Officer (CISO), Chief Information Officer (CIO), Head of Information Security in charge, handle ongoing website monitoring and respond to security alerts about suspicious changes. Web Security Managers and Security Architects will typically handle day-to-day tasks. Both compliance and security teams should evaluate a potential solution or tool.

Users

Someone from the software engineering or product development teams should monitor which scripts are present on and added to the website, and maintain the inventory. Developers are usually everyday users of potential PCI DSS solutions or tools.

Since the deadline (1 April 2025) to adopt future-dated requirements is already in the past, the main objective should be to make sure the PCI DSS compliance requirements 6.4.3 and 11.6.1 are adequately met and to simplify the compliance workflows as much as possible, and the right PCI DSS solution should help:

• Get a consolidated, real-time overview of vendors, scripts, and data.

• Reduce manual effort and fatigue with built-in risk analysis.

• Save time and resolve cases faster by automating manual checks.

Dedicated Client-Side Security Tools

There are several client-side security and PCI compliance vendors out there, and legitimate ways to meet the PCI DSS requirements 6.4.3 and 11.6.1.

Each PCI DSS v4 compliance tool has its advantages and disadvantages. What works best for you depends on your organization's size, your assessment needs, and your overall security posture. 

CSP/SRI 

Content Security Policy (CSP) helps modern browsers restrict which sources can load scripts or other assets, adding protection against data theft and other client-side threats while supporting PCI DSS anti-skimming controls. While Subresource Integrity (SRI) complements this by requiring external resources to match a predefined cryptographic hash, ensuring they haven’t been altered.

When teams review their security posture and PCI compliance solutions, the combination of CSP and SRI is often the first option. This browser-level control helps block injection-based attacks by defining which locations are permitted to serve JavaScript and other resources. In most implementations, the policy is delivered through an HTTP header, allowing the site to enforce strict rules on where scripts can originate. If you're interested in that approach, make sure to check out the white paper dedicated to it below. 

While CSP and SRI can contribute to PCI DSS v4 compliance, they also come with notable drawbacks that can complicate their use as primary controls. 

Implementing and maintaining CSP policies and SRI hashes can be resource-intensive, especially on dynamic sites with frequently changing or numerous third-party scripts, leading to significant operational overhead and potential functional breakages if hashes become outdated. Moreover, neither CSP nor SRI inherently detects runtime tampering or monitors unauthorized changes to scripts or security-impacting HTTP headers, leaving gaps in satisfying PCI DSS requirement 11.6.1 without additional tooling or processes.

Webpage Monitoring: Scanner (Agentless)

The scanner-based web monitoring solution is a “lightweight” option that many companies prefer, usually when they don’t have many payment pages and brands to manage. It is important to note that a scanner for PCI DSS requirements 6.4.3 and 11.6.1 is different from an ASV scan under PCI DSS requirement 11.2.

This tool offers a quick way to get started with PCI DSS v4, since there is no need for extensive integration and testing before going live. It usually works by scanning your designated payment pages, identifying all third-party services, and reviewing HTTP headers to verify they align with current security requirements. 

Although it can’t block activity like the agent-based approach we will cover next, it delivers the visibility and alerting required for PCI DSS requirements 6.4.3 and 11.6.1.

A key benefit of the scanner tools is that they accommodate situations where inserting code into the website isn’t feasible — for example, when the organization doesn’t directly manage the application or website. 

Webpage Monitoring: Agent

The agent-based tools for PCI DSS compliance offer several advantages that help easily meet PCI DSS requirements 6.4.3 and 11.6.1, as well as being proactive in detecting and optionally blocking suspicious behavior. 

The agent must be injected as a line of code, and monitors website activity 24/7. Because the agent works with real-time browser activity, it continuously observes and evaluates the behaviors flowing through the page.

What makes agent-based solutions stand out is that they enable comprehensive client-side protection and help drastically reduce authorizations. 

For companies that handle millions of transactions annually, it is critical to be proactive and block malicious activity and restrict third-party scripts from accessing customer data on payment pages. It is also helpful to have the option to review complex cases and analyze potential risks associated with third-party vendors and tags.  

Proxy-Based Solutions

Proxy-based solutions sit between the web server and the end user’s browser, giving them visibility into the scripts that are delivered to the client side. They can detect changes in first-party code and, in some cases, even evaluate third-party scripts to validate their integrity before they execute. 

These tools are typically divided into two groups: CDNs and reverse proxies. CDNs use a proxy to inject CSP headers, so it resembles a CSP deployment with automation on top. 

Reverse proxies dynamically tamper with HTML and scripts to prepend URLs with their own and to intercept every third-party hosted script. They can also use static analysis to detect changes.

How Jscrambler Can Help

Jscrambler believes that by making tamper detection and data loss prevention a continuous, proactive practice, organizations can maintain the integrity and trustworthiness of their payment pages while staying compliant with PCI DSS standards. 

Jscrambler gives companies the freedom to choose between agent-based and agentless solutions with a hybrid architecture. It is easy to start with a scanner and later proceed with an agent for comprehensive client-side protection and risk mitigation. With Jscrambler’s behavior-based monitoring, companies can reduce authorizations by about 90%.

The latest addition of an AI assistant to the Jscrambler client-side protection and compliance platform can help compliance teams manage compliance workflows with improved client-side security assurance and confidence.

How Scentbird Ensured Customer Trust with the Jscrambler PCI DSS solution

Jscrambler’s client, Scentbird, has an e-commerce perfume subscription platform built in-house. Developing a website from scratch came with some challenges: the platform had to be user-friendly and highly secure at the same time, and its payment page had to be approved by payment providers. To safely accept payments from thousands of customers, the team needed to be PCI DSS compliant. The Scentbird team considered it a priority to ensure that their customers could trust them with their data.

The Scentbird team initially reviewed cookie consent management tools that claimed PCI DSS support, but these options fell short because they lacked clear answers and practical guidance on PCI-specific requirements. They also considered large platforms like CDNs, which came with high costs and complex, time-consuming integrations. 

As Scentbird co-founder Andrei pointed out, while these platforms frequently introduce broad security features, they tend to address PCI DSS v4 only at a surface level rather than offering focused, in-depth compliance solutions.

With Jscrambler, Scentbird became PCI DSS-compliant in early 2024, well ahead of the 2025 deadline to adopt future-dated requirements and earlier than many e-commerce companies. 

Scentbird emphasized that proactive vendor support was a decisive factor, enabling the team to resolve issues quickly. Scentbird’s CTO and co-founder, Andrei, shared ‘If we have a question and it’s answered quickly, we’re happy. If there’s an upcoming release and we receive a notification several weeks in advance, we can prepare in time. I’d say that having strong support from the team is critically important, especially when it comes to client-side security and compliance.’ With stronger visibility and control over their payment page, the team felt more secure against JavaScript-based threats, giving leadership greater peace of mind and reinforcing the importance of ongoing client-side protection.

Stay up to date on client-side security and PCI DSS v4 compliance by following Jscrambler across our social channels. Connect with us on LinkedIn to get the latest insights, best practices, and product updates.