Navigating PCI DSS v4 Compliance: The CSP/SRI-Based Approach

In light of the upcoming PCI DSS future-dated requirements deadline (March 31st, 2025), many companies are evaluating tools and solutions to help them comply with the PCI DSS v4 anti-skimming requirements 6.4.3 and 11.6.1.

This article discusses Jscrambler’s new white paper, “The Hidden Costs of CSP/SRI for PCI DSS v4 Web Skimming Requirements”, which explores the benefits and caveats of the popular CSP (Content Security Policy) approach. While it might initially seem inexpensive, the financial and operational burden of using it for PCI DSS compliance is often much higher than anticipated. 

What are CSP and SRI?

Content Security Policy (CSP) is a W3C browser security standard that provides an extra layer of security in detecting and mitigating attacks that can result in data theft, site defacement, and malware distribution, among others. CSP, supported by all modern web browsers, offers a standardized way for website owners to limit the sources of their content(JavaScript, CSS, etc) that are allowed on their website. Essentially, CSP communicates its policies to the browser through an HTTP response header or HTML meta elements that browsers then enforce to strengthen security. CSP and SRI (Subresource Integrity) can be leveraged in conjunction with other processes to meet PCI DSS v4 anti-skimming requirements.

SRI is a security feature that allows browsers to ensure that loaded resources (such as those from a third-party domain) have not been tampered with. It achieves this by enabling you to specify a cryptographic hash that the resource must match.

What is needed to meet requirements 6.4.3 and 11.6.1?

In simple terms, PCI DSS v4 requirements 6.4.3 and 11.6.1 come down to the following: 

Requirement 6.4.3 

- Maintain an inventory of all scripts.

- Implement a method to confirm that each script is authorized.

- Document written justifications for the necessity of each script (business or technical reasons).

- Assure the integrity of each script.

Requirement 11.6.1 demands the deployment of a tamper-detection mechanism to:

- Alert personnel to unauthorized modifications to:

  - Security-impacting HTTP headers.

  - Script content as received by the consumer browser during the payment process (e.g., DOM-level).

The requirements’ goal is to reduce the risks associated with web skimming on payment pages or pages hosting the payment page (e.g. iframing them). By meeting the requirements, merchants become aware of scripts running on their payment pages. For more information on what kinds of data third-party vendors can access, check out this recent market research about the perils of third-party tags.

Key Highlights of a CSP/SRI-based Approach

How CSP/SRI help meet the requirements 

Even though there are multiple benefits of the Content Security Policy related to its main functions in preventing code injection, clickjacking, and other client-side vulnerabilities, this section will explore only what helps meeting  with PCI DSS v4 anti-skimming requirements.

Requirement 6.4.3

• Inventory of all scripts:

One technique that uses CSP to create a report is to roll out a very restrictive CSP policy in report-only mode. It essentially generates a CSP report per script that is loaded on the pages where the CSP policy is used. The sum of all reports will result in an up-to-date list of scripts (URLs). Of course, a URL doesn’t automatically say what the scripts are and what they do. That’s up to the organization to meet the requirements to determine.

• Script authorization:

CSP can enforce script authorization by allow-listing script URLs or by specifying script hashes in the script-src directive. Alternatively, SRI can validate (enforce authorization) a script’s integrity using precomputed hashes.

• Script integrity assurance:

SRI can ensure the integrity of scripts loaded with the integrity attribute.

CSP can allow-list specific URLs, which might prevent unauthorized scripts from being loaded, but it can’t assure the integrity of authorized scripts. To assure it, organizations can indicate script hashes, as mentioned before.

Requirement 11.6.1

• Script change detection:

CSP can alert when scripts deviate from authorized hashes, provided these hashes are included in the script-src directive.

The CSP and SRI are mentioned in the guidance column of the standard by the PCI Security Standards Council and are considered suitable to meet the requirements for PCI DSS v4 requirements 6.4.3 and 11.6.1. However, the PCI Security Standards Council does not provide advice or recommendations on how to implement the CSP and/or SRI. It is up to the assessed organization to determine how to meet these requirements and to complement them with other processes, as it’s not possible to meet all the demands of the two requirements with just CSP and/or SRI. The additional work necessary to meet the requirements completely can result in significant operational efforts, as discussed below.

Gaps and Challenges

At first glance, using CSP and/or SRI with additional processes might seem like a cost-effective approach to meeting PCI DSS v4’s anti-skimming requirements. However, a closer look at the practical implementation reveals significant hidden costs, both in terms of resources and operational overhead. The adoption of the CSP and/or SRI comes with significant operational, performance, and security challenges that have measurable cost impacts. 

Operational challenges

Initially, using CSP and/or SRI to meet PCI DSS v4’s anti-skimming requirements may seem cost-effective, but the practical implementation reveals significant hidden costs in resources and operational complexity. 

Firstly, maintaining a script inventory using CSP generates unmanageable report volumes, especially with dynamically changing third-party hosted scripts. Secondly, script authorization involves time-consuming risk assessments and frequent updates for third-party scripts, while manual documentation for authorized scripts adds further ongoing burden. Ensuring script integrity requires constant hash maintenance to avoid functionality breaks.

Maintaining hashes is not enough though, scripts have to be verified for the potential presence of skimming code, which CSP or SRI on their own do not provide. Having to do it constantly is labor-intensive and may result in alert fatigue, leading operational teams to approve scripts without the proper validation. Furthermore, monitoring HTTP headers necessitates separate systems. 

These processes demand substantial staff time, resulting in high operational expenditures (OPEX) that often exceed any initial cost savings, diverting resources from strategic priorities and risking compliance failure.

Security challenges

Security challenges also persist despite the implementation of CSP and/or SRI. While CSP and SRI enhance web security, their limitations make them insufficient for fully addressing PCI DSS v4’s anti-skimming requirements.

CSP’s URL allow-listing is widely known to be vulnerable to bypasses and cannot fully prevent compromised authorized scripts from executing malicious logic. Hash-based integrity enforcement is more secure but impractical for frequently changing or dynamically updated third-party scripts, creating blind spots in protection.

CSP and SRI also lack mechanisms to monitor or alert on HTTP header changes, therefore they do not contribute to meeting requirement 11.6.1. Additionally, CSP’s static configurations struggle to manage the dynamic nature of modern web ecosystems, requiring significant manual oversight prone to delays and errors. These shortcomings highlight the need for more comprehensive, automated solutions to effectively mitigate web skimming risks.

Website performance challenges

From a performance standpoint, CSPs can inadvertently disrupt website functionality. Their lack of granularity means scripts are either fully allowed or completely blocked.

SRI silently blocks mismatched hashed scripts, which could happen accidentally due to failure to timely update the hash signature. These facts increase the likelihood of breaking applications, which may be hard to detect quickly. Such issues may contribute to downtime, with severe financial repercussions—companies stand to lose anywhere between $145,000 and $540,000 per hour of downtime due to lost revenue, depending on the industry your organization is in. Additionally, the inability to fine-tune script permissions poses ongoing risks to operational efficiency and user experience.

Brief comparison between CSP/SRI, Agentless tools, and Agent-Based Solutions 

There are three main types of solutions accepted to give the merchants a compliance status: CSP and/or SRI, Website monitoring (Agentless monitoring and/or Agent-based solutions), and Proxy-Based solutions.

All three types of solutions are adequate and acceptable for PCI DSS v4 compliance. However, there are some differences. In the Jscrambler table below, you can see that in some aspects, certain solutions go further as they are specifically built for the PCI DSS v4 compliance, unlike the CSP and/or SRI.

Choosing a vendor-based solution over implementing CSP and/or SRI for PCI DSS v4 compliance offers a more sustainable, efficient, and cost-effective approach to mitigating web skimming risks. Vendor solutions provide comprehensive out-of-the-box compliance for all requirements, eliminating gaps left by CSP and/or SRI. Automation significantly reduces operational burdens by dynamically managing script inventories, logging justifications, and analyzing changes, freeing teams from repetitive tasks. Advanced technologies, such as behavioral analysis and runtime monitoring, enhance risk mitigation by adapting to threats in real-time.

Vendors can also manage compliance operations through services like Delegated Compliance, offered by Jscrambler, further simplifying management. While requiring upfront investment, vendor solutions reduce long-term operational expenses and offer predictable costs, ensuring scalability. With rapid deployment capabilities, vendors enable faster and more reliable compliance ahead of the April 1st, 2025 deadline.

Learn more from the white paper

To learn more about the efforts needed to make the CSP and/or SRI work properly, get the full version of the white paper “The Hidden Costs of CSP/SRI for PCI DSS v4 Web Skimming Requirements”.