Introduction of new requirements (6.4.3 and 11.6.1) for PCI DSS v4.0

This guidance is designed for any organisation seeking to comply with the new requirement 11.6.1 and 6.4.3 introduced in PCI DSS v4.0 while implementing PCI DSS in their environment. The suggestions outlined in this document are applicable to entities of all sizes, enabling them to assess the system components that should adhere to PCI DSS requirements. However, it is important to note that this guidance does not cover PCI DSS compliance itself. 

This guidance offers valuable information for individuals such as merchants, acquirers, issuers, service providers, and others who are accountable for fulfilling the PCI DSS requirements for their businesses. 

Acquirers who are assessing the PCI DSS Reports on Compliance or Self-Assessment Questionnaires of merchants or service providers can find useful insights in this document. 

The purpose of this document is to offer additional information. It is important to note that the information provided here does not override or replace any requirements stated in the PCI SSC Standard.

1. Introduction of new requirements (6.4.3 and 11.6.1) for PCI DSS v4.0

The introduction of version 4.0 of the PCI DSS brings forth several new requirements that e-commerce merchants will be assessed against starting from April 1, 2025.

In March 2022, the Payment Card Industry Security Standards Council released PCI DSS v4.0, a revised edition of its Data Security Standard. Notably, sections 6.4.3 and 11.6.1 introduce significant changes related to client-side security requirements. Section 6.4.3 specifically addresses the need for organisations to uphold the integrity of payment page scripts executed in the consumer's browser, even when sourced from third-party sites. This underscores the importance of implementing strong controls to safeguard all components involved in payment transactions.

1.1 Requirements 6.4.3 from PCI DSS v4.0

6.4 Public-facing web applications are protected against attacks.

6.4.3.  All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: 

• A method is implemented to confirm that each script is authorised. 
• A method is implemented to assure the integrity of each script. 
• An inventory of all scripts is maintained with written justification as to why each is necessary. 

PCI DSS v4.0 in-depth look at the new client-side security of requirements 6.4.3. The Payment Card Industry Data Security Standard (PCI DSS) v4.0 introduces new requirements for client-side security in order to enhance the overall security posture of payment card data. These requirements are designed to address the evolving threats posed by increasingly sophisticated cyberattacks and to ensure that payment card data is protected throughout its lifecycle, including during storage on client devices.

Exploiting vulnerabilities in payment scripts can lead to the compromise of account data. The attack surface grows larger as the number of scripts increases. To address these concerns, strict control measures are enforced, such as script authorization, integrity assurance, and inventory maintenance.

In section 6.4.3, the standard acknowledges the potential danger associated with client-side scripts, specifically highlighting that "scripts loaded and executed on the payment page can undergo changes in their functionality without the entity's knowledge, and can also incorporate external scripts." 

To address these potential threats, section 6.4.3 introduces three new PCI DSS compliance requirements pertaining to the management of scripts on payment pages. 

1.2 Instructions for implementing Requirement 6.4.3.

The following guidelines provide assistance in implementing Requirement 6.4.3, which is aimed at ensuring the security of payment page scripts.

• Implementation of a method to validate the authorization of each script. 

Authorization: To ensure proper authorization, it is important to establish a whitelist of permitted scripts. This entails creating a thorough list that includes the URLs, hash values, and intended purposes of each approved script. Additionally, mechanisms should be put in place to block any unauthorised scripts from being loaded and executed. Regularly reviewing and updating the whitelist is crucial to keeping it aligned with any changes to the payment page and conducting security assessments. 

Furthermore, it is advisable to consider implementing a Content Security Policy (CSP). This policy can help restrict the sources and behaviours of allowed scripts by utilising a CSP header. By doing so, an additional layer of security can be added to protect against potential threats.

• Implementation of a method to ensure the integrity of each script. 

Integrity: Ensure data integrity by employing cryptographic hash functions such as SHA-256 to calculate and retain hashes for every authorised script. Prior to execution, validate the integrity of the script by comparing its current hash with the stored hash to identify any alterations. Employ file integrity monitoring (FIM) tools to constantly monitor scripts for any unauthorised modifications. Additionally, consider utilising digital signatures as a means to authenticate and ensure the integrity of the scripts.

• Maintenance of an inventory of all scripts, accompanied by written justification for the necessity of each script.

Inventory and Justification: To ensure a comprehensive understanding of the system's components, it is crucial to create a detailed inventory. This inventory should encompass script URLs, sources, purposes, authorization methods, and integrity verification methods. By including these essential details, you can effectively manage and maintain your system's functionality. Furthermore, documenting the justification for each script is equally important. This documentation should provide a clear explanation as to why each script is necessary for the payment page functionality. By doing so, you can establish a solid foundation for our decision-making process and ensure that all scripts serve a purpose in enhancing the payment page experience.

Additional Factors to Consider:

Third-party scripts: Present a significant risk due to the potential for changes in the code, which can be updated at any time by the hosting provider. Such updates may inadvertently disrupt the functionality of a website or application. This risk is particularly evident if the script's hosting provider experiences a security breach or chooses to modify the script independently.

Additional risks associated with third-party scripts include:

• User privacy 
  Certain third-party scripts may gather or transmit user data, raising privacy concerns among users.
• Performance issues 
  The performance of a website or application can be adversely affected by third-party scripts, especially if they require excessive time to load or execute.
• Security vulnerabilities 
  If the script originates from an unreliable source or lacks adequate security measures, it may expose the website or application to exploitation by malicious entities.

To mitigate the risks associated with third-party scripts, consider the following strategies:

• Utilize reputable and well-established sources 
• Conduct regular vulnerability assessments and security scans 
• Monitor the online activity of your website 
• Implement stringent Content Security Policy (CSP) rules 
• Perform routine audits of site content 

Malicious code represents a potential risk associated with the utilization of hyperlinks from third-party sources.

This encompasses a range of threats, including viruses, worms, Trojan horses, and spyware. To protect your information and devices from such malicious code, it is essential to employ robust antivirus software and other cybersecurity measures, such as firewalls and advanced threat intelligence solutions.

Vulnerabilities in third-party scripts can exist regardless of whether the script is hosted externally. This poses a challenge, as hackers do not need to target a specific individual; they can exploit any vulnerability in the code that is imported, potentially affecting all users, including yourself.

Ongoing testing and monitoring: Regularly conducting vulnerability scans and penetration tests is essential in identifying any script-based attacks that may pose a threat to your system. By proactively identifying and addressing these vulnerabilities, you can enhance the overall security of your environment.  Incident response preparedness: It is imperative to have a well-defined incident response plan in place to effectively handle any script-related security incidents that may occur. This plan should outline the necessary steps to be taken in the event of an incident, ensuring a swift and efficient response to mitigate any potential damage or disruption.

Incident response plan: Have a plan to address script-related security incidents.

1.3 PCI DSS Requirement 6.4.3 and Mobile Payment Acceptance

The significance of PCI DSS Requirement 6.4.3 in relation to Mobile Payment Acceptance cannot be overlooked. This requirement emphasises the need for organisations to implement secure coding practices when developing mobile payment applications. By adhering to this requirement, businesses can ensure that their mobile payment acceptance systems are robust and resilient against potential security breaches.

Applicability to Mobile Applications: This applies to the payment pages found within mobile applications that handle cardholder data. It includes payment forms, payment gateways, and software development kits (SDKs) for card scanning. However, it does not apply to mobile wallets that tokenize data and do not store full card data. 

Key Requirements for Mobile Apps: Authorization and Restriction of Scripts: To ensure security, it is necessary to implement a whitelist that permits only approved scripts from trusted sources. Additionally, the use of Content Security Policy (CSP) is crucial in controlling the execution of scripts.

To prevent malicious execution, it is recommended to either disable or sandbox untrusted scripts. 

Script Inventory: Maintain a thorough record of all scripts and libraries utilised within the application. Document the purpose and relevance of each script. Conduct regular reviews and updates to keep the inventory accurate and up to date.

Additionally, conducting regular vulnerability scanning is crucial. In terms of documentation and monitoring, it is important to maintain a comprehensive list of authorised scripts and their sources. This will help ensure that only trusted scripts are executed. Furthermore, logging script execution attempts and actions taken will provide valuable insights for identifying and addressing any potential security threats.

Android: Incorporate app signing and integrity checks throughout the installation and update processes. Employ anti-tampering techniques to identify any unauthorised modifications. 

Script Authorization for Android: 

• Limit app execution to authorised sources. 
• Utilise digital signatures and certificate pinning to verify the authenticity of the app. 
• Implement runtime checks to prevent the execution of unauthorised code. 

Additional Factors to Consider: 

• Ensuring Secure Coding Practices: It is crucial to address vulnerabilities such as SQL injection, cross-site scripting (XSS), and buffer overflows. By implementing secure coding practices, potential security risks can be mitigated effectively. 
• Implementing Data Encryption: To safeguard cardholder data, it is essential to employ data encryption both during transit and while at rest. This ensures that sensitive information remains protected from unauthorised access. 
• Enhancing Device Security: To bolster overall security, measures like enforcing screen locks, enabling remote wipe capabilities, and implementing malware protection should be implemented. These steps help in safeguarding against potential threats and unauthorised access to devices.
• Third-Party Libraries and SDKs: It is crucial to give priority to third-party libraries and SDKs that adhere to PCI DSS compliance or have robust security practices in place. It is essential to thoroughly review their code and security documentation to ensure they meet the necessary security standards.

Apple's iOS and macOS have similar security measures as Android to ensure the integrity and authorization of apps.

Apple ensures app integrity and authorization through various measures. All apps distributed through the App Store must be digitally signed with a valid developer certificate, verifying their origin and preventing unauthorised modifications.

Furthermore, macOS's built-in security feature, Gatekeeper, blocks unsigned apps from running by default, providing an extra layer of protection against potentially harmful software. In terms of script authorization, both iOS and macOS apps operate within isolated sandboxes. This restricts their access to system resources and user data, preventing malicious scripts from compromising other apps or the operating system itself. 

Moreover, Apple's platforms employ a hardened runtime environment that enforces additional security restrictions. This makes it more challenging for attackers to exploit vulnerabilities and ensures a higher level of security. 

Lastly, macOS has specific security settings for scripting languages like JavaScript and AppleScript. These settings allow users to control which scripts can run and the actions they can perform, enhancing overall scripting security.

Additional Security Features:

• Apple incorporates additional security measures to safeguard user data and protect against potential threats. One such feature is the Secure Enclave, a dedicated hardware component that securely stores sensitive information like encryption keys and biometric data.
• In order to enhance security, Apple employs Address Space Layout Randomization (ASLR), a technique that randomises the memory locations of code and data. This makes it significantly more challenging for attackers to determine where to inject malicious code, thereby reducing the risk of unauthorised access.
• Another security feature implemented by Apple is Data Execution Prevention (DEP). DEP designates specific memory regions as non-executable, preventing the execution of injected code from those areas. This proactive measure acts as a deterrent against potential attacks and helps maintain the integrity of the system.

1.4 Purpose of the requirement 

Scripts loaded and executed in the payment page can have their functionality altered without the entity’s knowledge and can also have the functionality to load additional external scripts (for example, advertising and tracking, tag management systems). 

Such seemingly harmless scripts can be used by potential attackers to upload malicious scripts that can read and exfiltrate cardholder data from the consumer browser. 

Ensuring that the functionality of all such scripts is understood to be necessary for the operation of the payment page minimises the number of scripts that could be tampered with. 

Ensuring that scripts have been explicitly authorised reduces the probability of unnecessary scripts being added to the payment page without appropriate management approval. 

Using techniques to prevent tampering with the script will minimise the probability of the script being modified to carry out unauthorised behaviour, such as skimming the cardholder data from the payment page. 

1.5 Good Practice 

Scripts may be authorised by manual or automated (e.g., workflow) processes. 

Where the payment page will be loaded into an inline frame (iFrame), restricting the location that the payment page can be loaded from, using the parent page’s Content Security Policy (CSP) can help prevent unauthorised content being substituted for the payment page. 

1.6 Definitions 

“Necessary” for this requirement means that the entity’s review of each script justifies and confirms why it is needed for the functionality of the payment page to accept a payment transaction. 

1.7 Examples 

The integrity of scripts can be enforced by several different mechanisms including, but not limited to: 

• Sub-resource integrity (SRI), which allows the consumer browser to validate that a script has not been tampered with. 
• A CSP, which limits the locations the consumer browser can load a script from and transmit account data to. 
• Proprietary script or tag-management systems, which can prevent malicious script execution. 

The requirement (6.4.3) is designed to minimise the attack surface and manage all JavaScript present on the payment page. 

JavaScript is extensively utilised worldwide as a programming language, specifically in the context of e-commerce websites. The provided example below focuses on JavaScript settings that are relevant to requirement 6.3.4.

2. What is a JavaScript Form?

The JavaScript payment page originates from the merchant’s website and requests the customer’s browser to execute JavaScript code from the PSP to create the payment form. Entered cardholder data is then sent directly to the PSP in the same way as the Direct Post Method.  Merchants using a JavaScript e-commerce implementation may be eligible for PCI SAQ A-EP, providing they meet the eligibility criteria of that SAQ. 

2.1 The JavaScript Form process 

1. Merchant website creates the payment page. 
2. Payment page on the customer’s browser requests JavaScript from the PSP. 
3. The PSP creates JavaScript and sends it to the customer's browser. 
4. The customer’s browser uses JavaScript to create the payment form within the payment page. 
5. The customer completes payment by entering payment details into the form, which is sent directly to the PSP. 
6. The PSP receives cardholder data and sends it to the payment system for authorization. 

2.2 Key Elements of PCI DSS v4.0 Requirement 6.4.3 Implementation

In order to comply with Requirement 6.4.3 of PCI DSS v4.0, the implementation process requires specific elements to be addressed.

Inventory of Client-Side JavaScript: To ensure effective management and maintenance, organisations are required to maintain an inventory of all JavaScript scripts utilised on their payment pages. This inventory should provide detailed information such as the name, version, and purpose of each script, enabling organisations to have a comprehensive understanding of their client-side JavaScript resources.

Explicit Approval of JavaScript: Prior to execution, JavaScript scripts utilised on payment pages must undergo a meticulous approval process by an authorised individual. This approval is contingent upon assessing the script's functionality and determining its necessity through a comprehensive risk assessment.

Justification for JavaScript: Maintaining a record of approved JavaScript scripts is crucial for organisations to guarantee secure payment processing. This documentation should provide a clear explanation of why each script is necessary, emphasising its ability to enhance security and comply with the requirements of PCI DSS.

Regular Review and Updates: It is crucial to conduct regular reviews and updates of the inventory of JavaScript scripts, approval process, and justifications. This is necessary to keep up with any modifications in the payment processing environment or the introduction of new scripts.

Third-party JavaScript: It is crucial for organisations to exercise caution when integrating third-party JavaScript libraries or plugins on payment pages. Prior to their integration into the payment processing environment, these libraries should undergo a meticulous vetting process and receive approval.

3. Documentation and evidence you will need to provide during the assessment.

To meet the assessment criteria for this requirement, it is imperative to have the following documentation and evidence: 

1. Well-defined policies and procedures for effectively managing payment page scripts.
2. Comprehensive inventory records that encompass all scripts and API calls.
3. Written justifications for each script and API call listed in the inventory records.

Grasping the significance of PCI DSS v4.0 Requirement 6.4.3 extends beyond mere compliance efforts; it serves as an essential measure in safeguarding your customers' payment information. Compliance is no longer a discretionary choice but an imperative necessity for businesses. By implementing effective planning and utilising appropriate tools, you can effortlessly fulfil this requirement and pave the way for your business's prosperity.

The implementation of new client-side security criteria in PCI DSS v4.0 highlights the escalating significance of ensuring the protection of payment card data on client devices.

Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

3.1 Requirements 11.6.1. from PCI DSS v4.0

11.6 Unauthorised changes on payment pages are detected and responded to. 

11.6.1 A change- and tamper-detection mechanism is deployed as follows: 

• To alert personnel to unauthorised modification          

(including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser. 

• The mechanism is configured to evaluate the received HTTP header and payment page. 
• The mechanism functions are performed as follows: 

– At least once every seven days 

OR 

– Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1). 

Having already explored the broad modifications in PCI DSS v4.0 and conducted a comprehensive examination of the fresh client-side security prerequisites mentioned in section 6.4.3, let us now shift our focus to section 11.6.1. This particular update is of utmost importance as it carries significant implications for enhancing the security of online payment transactions.

The introduction of PCI DSS 11.6.1 in PCI DSS v4.0 requires the implementation of change- and tamper-detection mechanisms to protect sensitive payment card data from unauthorised modifications. This requirement specifically focuses on monitoring the HTTP headers and payment page contents received by the consumer browser. The main objective of PCI 11.6.1 is to promptly detect any unauthorised changes to these elements and take appropriate action to prevent data breaches or fraudulent activity.

PCI 11.6.1 highlights the significance of promptly identifying and addressing any unauthorised alterations on payment pages. Nevertheless, it is essential to establish the precise timeframe within which cybersecurity teams should respond upon receiving an alert. Additionally, PCI suggests updating mechanism functions either on a weekly basis or at regular intervals, depending on different factors. However, what does the term "periodically" exactly signify? This guide will further explore PCI 11.6.1, its requirements, and offer valuable insights on effectively implementing these guidelines to protect your organisation from client-side attacks. 

Essentially, PCI 11.6.1 emphasises the importance of implementing change- and tamper-detection systems on payment pages. These systems serve to notify authorised personnel about any unauthorised modifications. Additionally, the received HTTP header on the payment page must be evaluated. 

It is crucial to meet these requirements either every seven days or periodically. Requirement 11.6.1 mentions other time periods using the terms "timely" and "prompt" in relation to alert provision. 

This is evident in the Customised Approach Objective section, which states that e-commerce skimming code or techniques cannot be added to payment pages without generating a timely alert in the consumer browser. 

Similarly, anti-skimming measures cannot be removed from payment pages without generating a prompt alert. 

Ultimately, PCI 11.6.1 emphasises the need for prompt alerts when changes are made to your script. It is essential to have the necessary technology and resources in place to receive these timely alerts. While PCI allows some flexibility in the time allotted to detect and respond to alerts, it is crucial to consider how much time you can afford to wait before taking action.

The primary objective of this new regulation is to combat the growing threat of client-side attacks, such as cross-site scripting (XSS), formjacking, and web skimming attacks. In particular, the regulation focuses on Magecart attacks, which involve the injection of malicious scripts into payment pages to unlawfully acquire sensitive user data. These scripts can function in real-time, allowing for the unauthorised collection of payment card information as consumers input it.

3.2 Purpose 

Many web pages now rely on assembling objects, including active content (primarily JavaScript), from multiple internet locations. Additionally, the content of many web pages is defined using content management and tag management systems that may not be possible to monitor using traditional change detection mechanisms. 

Therefore, the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted. 

By comparing the current version of the HTTP header and the active content of payment pages as received by the consumer browser with prior or known versions, it is possible to detect unauthorised changes that may indicate a skimming attack. 

Additionally, by looking for known indicators of compromise and script elements or behaviour typical of skimmers, suspicious alerts can be raised. 

3.3 Exploring possible solutions for PCI DSS 11.6.1

Mechanisms that detect and report on changes to the headers and content of the payment page include but are not limited to: 

• Violations of the Content Security Policy (CSP) can be reported to the entity using the report-to or report-uri CSP directives (feedback mechanism for content-security-policy). 
• Changes to the CSP (Content-Security-Policy) itself can indicate tampering. 
• External monitoring by systems that request and analyse the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel. 
• Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behaviour is detected. 
• Reverse proxies and Content Delivery Networks (CDN) can detect changes in scripts and alert personnel. 

Often, these mechanisms are subscription or cloud-based, but can also be based on custom and bespoke solutions.

3.4 How PCI-DSS v4.0 requirement 11.6.1 compliance checks will work

The method employed to ensure compliance with section 11.6.1 of PCI-DSS is uncomplicated and direct:

11.6.1.a: System settings, all payment pages, and monitoring logs will be thoroughly examined to ensure there is a change and tamper detection mechanism deployed.

11.6.1.b: Configuration settings will be checked to ensure the mechanism has been set up compliantly and that it evaluates the received HTTP header and payment page. 

11.6.1.c: Businesses must either conduct weekly checks or conduct a risk assessment to determine the appropriate frequency of checks. An audit will involve analysing the risk assessment and confirming that the checks are being carried out at the required frequency.

In addition, PCI DSS v4.0 introduces a new method called the 'Customised Approach' to fulfil the requirements. This alternative approach allows for the utilisation of cutting-edge technologies and methods to achieve a control objective, even if they differ from the predefined requirement approach.

For section 11.6.1, in order to adhere to the customised approach, it is essential to ensure that e-commerce skimming code or techniques cannot be injected into payment pages without promptly generating an alert for the consumer's browser. Furthermore, it is crucial to have a prompt alert generated whenever any attempt is made to remove anti-skimming measures from payment pages.

3.5 Challenges with the implementation and recommendations

Purpose: Identify and take preventive measures against e-commerce skimming attacks in order to safeguard online transactions.

Challenges arise in the process of selecting suitable tools and technologies that can effectively meet the requirements. Additionally, integrating with pre-existing security systems poses another hurdle. Furthermore, managing alerts and distinguishing false positives can be a complex task. Lastly, addressing dynamic content and third-party scripts adds to the list of challenges that need to be tackled.

Exploring Potential Approaches to Overcome Challenges and Constraints 

Analysing Different Tool Alternatives: Content Security Policy (CSP), Synthetic User Monitoring (SUM), Tamper-resistant scripts 

Emphasise Prevention as the Primary Strategy: 

Implement proactive measures to block any attempts of executing malicious code. Minimise the need for relying solely on detection and response methods.

In the context of a customised approach for PCI DSS v4.0, it is essential to propose alternative controls that align with the core objectives. To effectively tackle dynamic content and third-party scripts, it is advisable to enforce strict controls and establish a comprehensive monitoring framework. Considering the implementation of whitelisting or code signing can be a viable solution.

Optimise Alerting and Response Mechanisms: Streamline the identification of false positives for improved accuracy. Establish transparent protocols for conducting thorough investigations and implementing effective remedial actions. 

Engage Relevant Stakeholders: Facilitate active participation of security, IT, development, and compliance teams to ensure comprehensive involvement. 

Stay Updated on Guidance and Best Practices: Leverage the resources offered by PCI SSC and stay informed about the latest industry insights and recommended practices.

3.6 Additional Recommendations: 

Implementing both sections 6.4.3 and 11.6.1 is crucial for any organisation accepting online payments. While it may require financial investment and technical expertise, the cost of non-compliance can be significantly higher. 

1. Prior to implementing any solutions, it is crucial to conduct comprehensive evaluations of vendors. This will ensure that the chosen solutions meet the necessary requirements and standards.
2. It is important to regularly test and update detection mechanisms to enhance their effectiveness. By doing so, potential vulnerabilities can be identified and addressed promptly.
3. Providing training to staff members on how to identify and respond to alerts is essential. This will enable them to take appropriate actions in a timely manner, minimising the impact of security incidents.
4. Considering managed security services can provide valuable expertise and support. These services can offer specialised knowledge and assistance in managing and mitigating security risks. Seek guidance from qualified security professionals to assess your risks and implement effective controls.

Staying informed: Keep up-to-date with the latest security threats and PCI DSS updates to maintain a robust security posture.

Remember: Continuous assessment, adaptation, and collaboration are key components of maintaining effective compliance. Regularly reviewing and improving security measures is crucial in today's ever-evolving threat landscape.

Consider: Investing in security solutions: Implement content security policies, script integrity monitoring, and other security tools to enhance client-side security.

Note: This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

4. Exploring the Implementation of E-commerce

E-commerce, commonly referred to as electronic commerce, involves the utilisation of the Internet to facilitate transactions for the buying and selling of goods and services. It operates as a payment channel where physical card presence is not necessary. An e-commerce solution encompasses the software, hardware, processes, services, and methodology required to enable and support these transactions. Merchants have the flexibility to choose from a range of technologies, including payment-processing applications, APIs, iFrames, or third-party hosted payment pages, to implement e-commerce functionality. This section explores various e-commerce implementations and provides illustrative examples.

4.1 iFrame Payment Flow example 

The following diagram depicts the customer journey and cardholder data flow for Clinet’s iFrame ecommerce implementation.

1. The merchant website creates an iFrame within the current webpage. The customer’s browser requests the payment form from the PSP. 
2. The PSP creates a payment form and sends it to the customer’s browser within the iFrame. 
3. The customer’s browser displays the payment form within the iFrame located on the merchant page. 
4. The customer enters their payment details into the iFrame containing the PSP’s payment form. 
5. The PSP receives the account data and sends it to the payment system for authorization. 

At present, a merchant implementing an e-commerce solution that uses iFrames to load all payment content from a PCI DSS compliant service provider may be eligible to assess its compliance using a reduced list of controls identified in SAQ A, the smallest possible subset of PCI DSS requirements, because most of the PCI DSS requirements are outsourced to the PSP. The full list of eligibility requirements for use of this reduced self-assessment questionnaire is outlined within the SAQ A document. 

However, despite the fact that merchants using iFrame implementations may be eligible for SAQ A, these types of e-commerce solutions are susceptible to compromise by a determined attacker, and merchants should ensure that they are appropriately addressing this risk.

iFrames provide a degree of security by relying on a technique known as the same-origin policy, which is enforced by all modern web browsers. The assessor will need to verify the merchant is getting the protection expected. This prevents malicious scripts on the merchant’s website from interacting with the contents of the third-party content (i.e., the payment form) in the frame. This makes it more difficult for an attacker with control of the merchant’s website or other third-party content providers to silently monitor and steal cardholder data. 

If an attacker has compromised the merchant’s website, however, they can create alternative content for the frame, which then allows completion of the payment process as well as creation of a copy of the cardholder data for the attacker. Without monitoring and alerting controls on the merchant’s infrastructure, attacks of this nature might be impossible to detect. 

Merchants should consider complementing their PCI DSS compliance program with additional security controls to reduce e-commerce risk, even if such controls are not stated as required by SAQ A. Hardening of servers, vulnerability management, and monitoring of server activity are effective controls for these implementations.

4.2 The Direct Post process example 

1. The merchant’s website creates the payment page. 
2. The customer’s browser displays the payment page and sends cardholder data directly to the PSP. 
3. The PSP receives the cardholder data and sends it to the payment system for authorization. 

As account data is not stored, processed, or transmitted on the merchant’s e-commerce systems, a subset of security controls is required to protect the web server and, in particular, the payment form due to the merchant’s control over the manner in which cardholder data is collected and transmitted to the PSP. Because of this, there is an associated security effort, such as network and firewall security, secure software development, vulnerability scanning/penetration testing, and vulnerability and patch management. For a full list of requirements, please see the applicable SAQ. 

Merchants using a Direct Post e-commerce implementation may be eligible for PCI SAQ A-EP, providing they meet the eligibility criteria of that SAQ.

4.3 The Application Programming Interface (API)

The merchant system’s handling of cardholder data in the API method may require that the entire set of PCI DSS controls be applied to the merchant’s in-scope systems, people, and processes.

The API Process 

1. Merchant creates a payment page. 
2. Customer’s browser displays the payment form. 

3. The customer enters cardholder data into the payment form and the data is sent to the merchant web server. 
4. The merchant web server transmits cardholder data to the PSP. 
5. The PSP receives cardholder data and sends it to the payment system for authorization. 

This architecture carries a high risk for merchants as their systems will receive and transmit, and may also store and process, cardholder data. Hackers target websites using this payment method because there is a greater chance of larger amounts of valuable cardholder data being available, and the attack can be easier due to varying levels of security controls among merchants. Due to the higher risk of compromise to merchant systems, the level of security responsibly for the merchant is high. 

Merchants using the API e-commerce payment method may be eligible for SAQ D, providing they meet the eligibility criteria of that SAQ.

4.4 Shared-Management E-commerce – URL Redirects

Please follow the SAQ Completion Guidance below for instructions on utilising the redirect option. 

SAQ Completion Guidance: If a merchant chooses to employ URL redirects, wherein the merchant hosts the page(s) on their website(s) that provide the address (URL) of the TPSP's/payment processor's payment page/form to the merchant's customers, the merchant shall indicate this requirement as Not Applicable and proceed to complete Appendix C: Explanation of Requirements Noted as Not Applicable.

What is a URL Redirect? 

In the URL redirection model, the cardholder is redirected from the merchant’s website to a third-party page. The cardholder then enters their account data into a payment page hosted by the third-party payment service provider (PSP). This may also be called a “punch out” since customers and application users are sent to a PSP’s web pages. This is generally noticeable to the customer as the merchant’s website URL. 

The Redirect Process example

1. Merchant website sends a redirect command to the customer’s browser. 
2. The customer’s browser then requests a payment form from the PSP. 
3. The PSP creates the payment form and sends it to the customer’s browser. 
4. The customer’s browser displays the PSP’s payment form. 
5. The customer enters account data and sends it to the PSP. 
6. The PSP receives the account data and sends it to the payment system for authorization. 

As account data is not collected, stored, processed, or transmitted by the merchant’s system, fewer systems need security controls. As redirects are commonly used by small and medium business organisations with lower-than-average cardholder data volume, it is less likely an attacker would target a merchant with this type of payment method. However, it is still important for merchants using a URL redirect to ensure their websites are secure, as a compromised web server could mean the redirect is changed to a bogus payment site in order to steal cardholder data—e.g., man-in-the-middle attacks wherein the web server collects and sends data to malicious individuals. 

This e-commerce option provides an easier way for merchants to provide security for cardholder data, as most of the cardholder data security is performed by the PSP. As the PSP collects, stores, processes, and transmits cardholder data on behalf of the merchant, it is strongly recommended that a merchant ensure the PSP is validated as a PCI DSS compliant service provider to protect the merchant’s cardholder data and enable an easier PCI DSS compliance route. 

Merchants using a URL redirect e-commerce implementation may be eligible for PCI SAQ A or SAQ A-EP, providing they meet the eligibility criteria of that SAQ.

5. Conclusion 

E-commerce merchants who have traditionally enjoyed a reduced scope PCI DSS assessment will not need to implement technical controls for PCI DSS compliance.  The technical requirements are the responsibility of the merchant for implementation. 

Failure to adhere to the latest PCI DSS standards, particularly Section 11.6.1 and 6.4.3, not only exposes your business to significant financial penalties but also undermines consumer trust, which can have lasting negative effects on your brand. It is crucial to recognize the gravity of these consequences and avoid any delay or underestimation in complying with the standards.

5.1 Potential Consequences of Failing to Comply with PCI DSS v4.0 Requirement 6.4.3 and 11.6.1.

Possible Ramifications of Non-Compliance.

Without the tamper-detection mechanism mandated by 11.6.1, organisations remain vulnerable to such attacks, leading to:

1. Heightened Susceptibility to Magecart Attacks: Magecart attacks involve injecting malicious code into websites or third-party scripts, enabling the theft of payment card data directly from users' browsers.

Failure to implement the tamper-detection mechanism required by 11.6.1 leaves organisations exposed to such attacks, resulting in:

• - Breaches of cardholder data: This exposes sensitive information such as card numbers, names, and CVVs, leading to significant financial losses and damage to reputation.
• - Imposition of regulatory fines: Non-compliance with PCI DSS can result in substantial fines imposed by payment card brands and regulatory bodies.

2. Increased Risk of Data Breaches: Non-compliance with PCI DSS 4.0 Sections 6.4.3 and 11.6.1 raises the likelihood of data breaches. This can lead to unauthorised access to cardholder information, potentially causing severe financial and reputational harm to organisations.
3. Loss of Customer Trust: Failing to adhere to PCI DSS requirements undermines customer trust. Non-compliance can result in customers losing confidence in an organisation's ability to protect their payment card data, leading to a decline in business and potential damage to long-term relationships with customers.

It is crucial for organisations to prioritise compliance with PCI DSS 4.0 Sections 6.4.3 and 11.6.1 to mitigate these potential outcomes and safeguard their reputation, customer trust, and financial well-being.

4. Operational disruptions: Dealing with a breach can be resource-intensive, disrupting regular operations and impacting productivity
5. Increased insurance premiums: Companies that experience breaches may encounter higher insurance premiums due to the perceived security risk

The importance of ensuring the security of all scripts used in payment pages, including those provided by third parties, is highlighted in Section 6.4.3. Failing to do so can expose organisations to a range of risks. Additionally, there are further repercussions that organisations may encounter if clients utilise insecure payment pages. Requirement 6.4.3 emphasises the need to secure all scripts involved in payment pages, including those sourced from third parties. Neglecting this can create opportunities for malicious scripts, Formjacking attacks, session hijacking, and the theft of sensitive data.

Organisations can greatly mitigate the risk of breaches and safeguard their customers' sensitive data, reputation, and business operations by taking proactive measures to address vulnerabilities on the client-side. It is imperative to align script management practices with the requirements of PCI DSS. By effectively managing scripts, organisations can fortify the security of payment pages and protect sensitive payment data from potential attacks. Implementing these controls will not only help meet Requirement 6.4.3 but also enhance the overall security posture.

6. Appendices

6.1 Appendix A: Abbreviations