Effective April 1st, 2025, PCI DSS v4.0 introduces additional requirements—6.4.3 and 11.6.1—that specifically target the security of e-commerce payment pages. Unlike previous versions, which focused on server-side protection, these updates address client-side risks posed by third-party scripts, which are vulnerable to attacks commonly known as e-commerce skimming (also known as web skimming or Magecart attacks).
PCI DSS requirement 6.4.3 mandates rigorous management and monitoring of all scripts executed on consumer browsers during payment transactions. This includes ensuring each script is authorised, maintaining script integrity, and documenting business justifications for their presence.
Requirement 11.6.1 complements this by necessitating a mechanism to detect and alert unauthorised modifications to HTTP headers and scripts on payment pages. These checks mitigate risks associated with client-side attacks that traditional server-side security measures may overlook.
Organisations can achieve compliance through three primary approaches: utilising redirected payment pages, developing in-house solutions employing technologies like Sub-resource Integrity (SRI) and Content Security Policy (CSP), or opting for third-party solutions designed to manage and monitor scripts effectively.
Each approach carries distinct pros and cons. Redirected payment pages simplify compliance but may affect customer experience. In-house solutions offer control but require significant resources and expertise. Third-party solutions provide specialised tools but incur additional costs.
Immediate action is advised to ensure readiness by the deadline. Planning and implementation timelines vary for each approach, necessitating early consideration and strategic decision-making to align with organisational needs and budget constraints.
Preparing now ensures compliance with PCI DSS v4.0 requirements and safeguards against data breaches, financial penalties, and reputational damage. Organisations can uphold security standards by proactively managing and monitoring third-party scripts and effectively protecting customer payment information.
This blog is your guide to understanding these changes, why they matter, and how you can navigate them to ensure your e-commerce platform remains secure and compliant.
PCI DSS v4.0 recap
The PCI DSS, or Payment Card Industry Data Security Standard, is a set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. With the release of version 4.0, the PCI Security Standards Council introduced several updates to better address current security threats and enhance existing controls. The recent release of version 4.0.1 has further clarified the intent of some PCI requirements.
Among the updates, the emphasis on client-side security for e-commerce websites stands out, particularly with requirements 6.4.3 and 11.6.1. These new requirements focus on managing and monitoring the third-party scripts on your payment pages—a crucial area often targeted by cybercriminals.
What is PCI DSS requirement 6.4.3?
What does the standard say?
“6.4.3: All payment page scripts that are loaded and executed in the consumer’s browser are managed”
To meet the requirement, you must:
- Implement a method to confirm each script is authorised.
- Assure the integrity of each script.
- Maintain an inventory with business or technical justification for each script.
In simplistic terms, this requirement is designed to ensure that unauthorised code is not present on the payment page. This requirement means you must only allow authorised scripts to run on payment pages, and each script must have a business or technical justification. An inventory of all scripts and their justification must also be maintained.
In addition to documenting which scripts are approved and why, the script’s integrity must be assured. In practice, this means you must ensure they have not been altered to include functionality beyond what you have approved. This includes authorised third-party scripts loading additional external (fourth-party scripts) that you have not explicitly approved.
Why is this challenging?
All e-commerce organisations use scripts extensively on their websites for various legitimate reasons. These typically include scripts that provide a good customer experience and track customer behaviour and browsing habits. Many of these scripts are provided by third parties, who take data from your website and analyse it in some way on your behalf, for example, for tracking adverts and traffic. To complicate things further, they may even include additional third-party scripts beyond even their control.
This is a challenge because you need direct visibility or control over changes as the scripts are hosted externally; your script provider can make changes whenever they need to without your involvement.
Malicious code inserted anywhere in this chain of scripts can ultimately end up in your customers’ browsers when they access your payment page.
What is PCI DSS requirement 11.6.1?
What does the standard say?
“11.6.1: A change and tamper-detection mechanism is deployed”
To meet the requirement, you must:
- Generate alerts for unauthorised modification to the security-impacting HTTP headers and scripts on your payment pages.
- Evaluate the HTTP headers and payment pages received by the consumer’s browser.
- Perform the checks weekly or periodically as per your defined risk appetite.
Requirement 6.4.3 is focused on ensuring that any scripts running on your payment page are authorised and their functionality is necessary. Requirement 11.6.1 builds on this further by ensuring you can detect potentially malicious changes in the page loaded in the consumer’s browser.
Why is this challenging?
Much of what customers see on your website is built dynamically in their local web browser, assembled using data pulled from multiple locations using scripts and content management systems. The dynamic nature of how pages are built in the browser has made client-side attacks a common target, with criminals attempting to modify scripts to target data entered on the payment page.
Malicious changes to that content cannot be easily detected through more traditional server-side checks, so requirement 11.6.1 requires you to detect these changes on the client side.
How to meet PCI DSS requirements 6.4.3 and 11.6.1
There are several ways to meet these requirements, and the PCI DSS provides guidance on how to do so. Three high-level approaches we recommend reviewing are:
- Use a redirected payment page.
- Create an in-house solution.
- Use a third-party solution.
Use a redirected payment page
Technically, this approach doesn’t meet requirements 6.4.3 or 11.6.1, but it does make them not applicable to your e-commerce environment. By entirely redirecting your customers to a hosted payment page (i.e., not using an iFrame or a direct post solution), you ensure that all scripts are loaded directly from the third-party payment processor’s website, over which you have no control.
You’re still responsible for other applicable requirements, including managing your relationship with the payment processor and monitoring their PCI DSS compliance (requirement 12.8), but 6.4.3 and 11.6.1 aren’t applicable to you for a full redirect.
From a pure risk-reduction perspective, this is a strong option, as it outsources all of the risk and controls to a PCI DSS-compliant service provider whose core focus is payment security.
Pros The pros of using a fully redirected payment page are that it simplifies your PCI DSScompliance and reduces the risk of script-related issues, as these are fully outsourced. You also don’t need to implement new processes and technology, which reduces the ongoing cost of the requirement. | Cons The cons of using a fully redirected payment page are that you lose control of the customer’s experience. The customer payment journey moves fully away from your website, and the customer will see that they have been redirected to a third-party provider. Unfamiliar payment gateways and unexpected changes to the URL are also known to make cart abandonment more likely. Initial development time must be invested in making changes to your payment journey to implement the redirect. |
Create an in-house solution
Organisations that want to avoid completely changing the checkout process to use a redirect must implement technology and processes to meet this requirement. The PCI DSS provides some examples of how to do this.
For 6.4.3:
- Sub-resource integrity (SRI) allows validation that a script has not been tampered with. This validation is performed in the customer’s browser based on the configuration you supply.
- A Content Security Policy (CSP) can be used to control and limit where the consumer browser can load data from and transmit data to.
- A script or tag-management system can be used.
For 11.6.1:
- Report any CSP violations.
- Monitor for changes to the CSP.
- Use external systems to periodically check that your content has not changed by comparing it to a “known good” state (Synthetic Monitoring).
- Alert or block when malicious behaviour is detected using tamper detection scripts on the payment page.
- Use a third-party reverse proxy or content delivery network.
Pros The pros of creating an in-house solution are that you retain full control over the implementation. CSP can be used to authorise which scripts can run, and control where data loads from, and where it’s sent. CSP can also be used to report any violations back to you for review. SRI addresses the need for script integrity, and processes can be implemented to address the approval and inventory requirements. With this option there is no need to buy an off-the-shelf solution, which makes it appealing if budget is a concern. | Cons The cons of creating an in-house solution are that CSP and SRI are complex and time-consuming to develop and maintain. This approach relies on having in-house expertise, and a team in place for ongoing monitoring and updates. There’s also a very real risk that you’ll break your payment page and be unable to take card payments if you fail to update your configuration before changes are made. Script code and behaviour change frequently, including scripts provided by third and fourth parties who may make changes with no warning. |
Use a third-party solution
Another approach is to purchase an off-the-shelf solution to address your requirements. This may be the best option for organisations that don’t want to implement full redirects but also lack the technical expertise or capacity to develop and maintain an in-house solution.
Pros The pro of using a third-party solution is that you are taking advantage of technology designed specifically to address the risks these new requirements are trying to mitigate against attacks. Because CSP and SRI are functions that run in the consumer browser, there’s generally no need to implement new software in your own environment, with the controls being applied through code. Most solutions also offer tools to help configure and fine-tune your policies, and simplify monitoring any alerts and violations that might occur. | Cons The obvious con of using a third-party tool is the cost. Depending on how many e-commerce payments you’re taking and the number of websites you are using, the cost will vary. You’ll also need to evaluate solutions to ensure they meet your requirements and balance the cost of an off-the-shelf tool against the development and ongoing operational costs of building your own solution. |
The time to act is now
These new requirements apply from 1st April 2025 and are considered best practice until then. Blackfoot recommends that you start planning today for whichever approach you take. All three options discussed here will require time to plan and implement:
- Changing to a redirect solution will require time to redevelop your checkout process and engage a third-party service provider who can provide a fully hosted payment page.
- Developing an in-house solution will take time and require additional training and resources to complete the development and testing.
- Procurement processes may delay the purchase of a third-party solution. Although a service provider handles much of the complexity, limited setup and development time are still required.
Frequently asked questions
1. What is the primary purpose of PCI DSS requirement 6.4.3?
Requirement 6.4.3 aims to manage and authorise third-party scripts on payment pages to prevent unauthorised access and data breaches. By vetting and monitoring all scripts, you can protect your site from malicious activities that compromise sensitive customer data.
2. Why is monitoring necessary in PCI DSS requirement 11.6.1?
The requirement states that checks are performed at least weekly or based on an interval determined using a risk assessment. A QSA can’t mandate real-time monitoring, but more frequent checks are strongly recommended. Monitoring helps detect unauthorised script changes promptly, preventing e-skimming and other client-side attacks. This proactive approach ensures that any suspicious activity is identified and addressed before it can cause harm, thereby protecting customer payment data.
3. Can I use third-party tools to comply with these requirements?
Yes, third-party tools can help manage and monitor scripts, reducing the internal resource burden and leveraging industry expertise. These tools often have built-in capabilities to handle authorisation and real-time monitoring, making compliance easier.
4. What are the challenges of implementing these requirements in-house?
Developing in-house solutions requires significant resources, expertise, and ongoing maintenance to ensure compliance and effective monitoring. The complexity of managing and authorising scripts, along with continuous real-time monitoring, can strain internal teams without the right tools and processes.
5. How does using a redirected payment page help with compliance?
Redirected payment pages simplify compliance by reducing the need to manage and monitor third-party scripts on your site, as the payment process is handled externally. This approach minimises the risk of unauthorised script changes and e-skimming attacks but may impact user experience.
6. What are the risks of not complying with PCI DSS 6.4.3 and 11.6.1?
Non-compliance can lead to severe consequences, including data breaches, financial penalties, and damage to your brand reputation. Unauthorised scripts can compromise customer information, leading to loss of trust and potential legal issues.
7. How can I ensure my third-party scripts are authorised and secure?
Implement a robust authorisation process that thoroughly vets all third-party scripts, maintains an up-to-date inventory, and uses tools like Content Security Policy (CSP) and Sub-resource Integrity (SRI) to enforce and verify script integrity.
8. What should my incident response plan include for script monitoring?
Your incident response plan should include procedures for detecting and addressing unauthorised script changes, communication protocols for notifying stakeholders, steps for mitigating the impact, and regular reviews and updates to the plan based on new threats and vulnerabilities.
9. What is sub-resource integrity (SRI)?
SRI is a security feature that ensures the integrity of scripts and other resources loaded on your web pages. Using SRI, you can provide a cryptographic hash for your scripts, allowing the browser to verify that the fetched resource matches the expected hash before executing it. This prevents attackers from tampering with the scripts and injecting malicious code.
10. What is content security policy (CSP)?
CSP is a security standard that helps prevent various types of attacks, such as cross-site scripting (XSS) and data injection attacks. CSP allows site owners to control which resources the browser is allowed to load for a page. CSP works by specifying directives in HTTP headers. These directives define allowed content sources for scripts, styles, images, and other resources.
11. What is e-commerce skimming?
E-commerce skimming, also known as web skimming or Magecart attacks, involves cybercriminals injecting malicious code into e-commerce websites to steal payment card information during checkout. These attacks typically target scripts loaded on the payment pages, where they can capture and exfiltrate sensitive data. Attackers exploit vulnerabilities in third-party scripts or directly inject malicious scripts into the website. When customers enter their payment details, the skimming code captures this information and sends it to the attackers.
12. What are some good resources for learning more about CSP and SRI?
Plenty of educational resources are available to learn more about CSP and SRI, including MDN Web Docs, OWASP, Google Web Fundamentals, and W3C.
Please note: Information about specific PCI DSS requirements has been shortened for easy reading. Always refer to the entire PCI DSS standard for comprehensive details and additional guidance, and ensure you consult a QSA for questions specific to your payment environment.
The PCI DSS and other supporting documentation can be viewed for free on the PCI SSC’s website www.pcisecuritystandards.org.
If you would like to discuss how these changes apply to your organisation or need any assistance meeting these new requirements, you can get in touch with one of our consultants here.
