As a leading provider of web application and API security solutions, Imperva is committed to helping merchants, payment processors, and anyone seeking to comply with the latest PCI DSS requirements. We previously discussed the changes introduced in PCI DSS 4.0. This blog will cover the clarifications introduced in version 4.0.1 regarding payment pages, forms, and script responsibility, precisely requirements 6.4.3 and 11.6.1.
While version 4.0 marked a significant leap forward, including 64 new requirements spread across 3 phases, version 4.0.1 serves a different purpose, offering essential clarifications to the previous version. Although no new requirements were added, these updates provide improved clarity and guidance for organizations aiming to achieve compliance.
Applicability: Clarification on The Scope of Client-Side Security Requirements
One area where version 4.0.1 shines is in its applicability notes. Like us at Imperva, PCI understands that most merchants nowadays use Payment Service Providers or Third-Party Service Providers (PSPs or TPSPs) instead of creating the payment form themselves. This can be either via a form loaded into an iframe embedded on the checkout page or a redirect to a separate page owned and managed by a third party.
Due to this, many merchants previously believed that embedding payment pages from a third-party relieves them from the need to comply with these new requirements. However, PCI DSS 4.0.1 addresses this by moving applicability notes from SAQ A into the main document.
Three new applicability notes have been added to clarify the scope for entities’ web pages and TPSPs embedded payment pages/forms. This clarification addresses the common question of script compliance ownership between merchants and TPSPs, providing much-needed clarity for organizations looking to comply.
By doing so, PCI DSS 4.0.1 clarifies the requirements, ensuring they now apply to all merchants, including those previously considered SAQ-ineligible. This change enhances overall security and compliance.
Requirement 6.4.3 – Who is Responsible for Scripts?
Requirement 6.4.3 has been updated to clarify that merchants are only responsible for scripts loaded into their own web pages (the parent page) and not for scripts loaded in an iframe containing a payment page from a payment processor/TPSP (PSP). The PSP is solely responsible for managing the scripts within the iframe. This highlights the shared responsibility.
To bring the script authorization process into the modern era, guidance has been added for situations where scripts cannot be authorized before being changed or added. This acknowledges that it’s unrealistic to expect all scripts to be vetted beforehand and instead emphasizes the importance of real-time monitoring and mitigation to protect cardholder data.
Merchant and PSP Responsibilities
The updated requirement 6.4.3 also includes guidance on what merchants should expect from PSPs. According to the “good practice” section of the Guidance, entities that contain TPSP/Payment Processor’s embedded payment page/form on their webpage should expect the TPSP/Payment Processor to provide evidence that they are meeting this requirement, as per their PCI DSS assessment and Requirement 12.9.
While this advice is helpful for PSPs, we at Imperva believe it needs to make more security sense for scripts loaded into a different cross-origin iframe from any non-payment-related Third-Party Service Provider.
A Note on Good Practice for 6.4.3
A critical addition for 6.4.3 is the “good practice” recommendation to validate and restrict the sources that can be loaded in the iframe. This means that even organizations with only an iframe on their payment page would benefit from using CSP headers with the frame-src directive, specifying valid sources for nested browsing contexts like <frame> and <iframe>.
Requirement 11.6.1 – Security-Impacting HTTP Headers: Focus on What Matters
The clarification around 11.6.1 is a significant development, focusing on security-impacting HTTP headers and script contents. This approach reduces noise from routine website builds by concentrating on critical security-related events. It’s a move that aligns with the original intention of monitoring scripts and only scrutinizing HTTP headers that matter.
Two significant clarifications have been added to the “defined approach” under requirement 11.6.1 in version 4.0.1. The original requirement was to detect unauthorized changes to “the HTTP headers and the contents of payment pages as received by the consumer browser.”
This has been updated to clarify that only cardholder data security changes are relevant, focusing on “security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.”
The change reflects how most entities were interpreting the requirements. This clarification highlights the importance of monitoring for security-relevant changes.
Improved Guidance
The updated guidance clarifies why checking HTTP headers helps detect skimming attacks. It mirrors the “good practice” from 6.4.3, which states that PSPs should provide evidence they are meeting the requirement and details that a combination of approaches or tools can be used to meet the requirement.
By understanding these clarifications and updates, merchants and payment processors can better navigate the complexities of PCI DSS 4.0 and ensure cardholder data security and compliance.
With just nine months remaining until March 31st, 2025, the deadline, organizations must create new requirements existence pages and comply with PCI DSS 4.0.1.
While it is helpful to consider using a combination of approaches to meet these new requirements, adopting a dedicated solution tailored at addressing them is recommended.
Imperva Makes Complying with PCI DSS 4.0.1 a Breeze
Part of the Imperva Application Security Platform, Client-Side Protection simplifies compliance with the new client-side security requirements introduced in PCI DSS 4.0. The PCI Dashboard addresses these requirements by clearly explaining each requirement and identifying related action items. It validates content security policy headers, offers weekly summaries for payment page changes, and helps you stay audit-ready while monitoring compliance-affecting changes easily.
Onboard your entire website or just the payment page for complete script visibility. Authorize each script via UI or API and receive alerts on new script versions and hashes. Maintain a comprehensive list of third-party, inline, and origin scripts with the ability to add notes and justifications. Gain visibility and control over newly discovered or modified forms, headers, iframes, and data transfers. Ensure content-security-policy headers are accurately injected into consumer browsers, and stay informed with weekly summaries of any changes to your payment page content. Achieve seamless compliance and enhance your client-side security with our robust solution.
The post PCI DSS 4.0.1: New Clarifications on Client-Side Security – What You Need to Know appeared first on Blog.
