PCI DSS FAQ Chronicles: Clarifying the Application of Requirement 6.4.3 to 3D Secure (3DS) Scripts

As e-commerce grows, so do the complexities of securing online payment transactions. One crucial method for enhancing security during online payments is the use of 3D Secure (3DS), a protocol designed to authenticate cardholders during online transactions. But how does PCI DSS apply to 3DS scripts that are called from a merchant's checkout page, and what role does Requirement 6.4.3 play in protecting these interactions? In this article, we dive into the details of 3DS, the intention behind PCI DSS Requirement 6.4.3, and how this requirement applies to 3DS scripts.

1. What is 3D Secure (3DS)?

3D Secure (3DS) is an online security protocol used to authenticate cardholders during digital transactions. Introduced by Visa (as Verified by Visa) and adopted by other major card brands like Mastercard (Mastercard SecureCode), 3DS is a vital mechanism for reducing fraud during online card-not-present (CNP) transactions.

The term "3D" refers to the three domains involved in the authentication process:

1. Issuer Domain: The card issuer (e.g., the bank that issued the payment card) authenticates the cardholder.
2. Acquirer Domain: The merchant’s bank or payment processor.
3. Interoperability Domain: The infrastructure provided by the payment networks (e.g., Visa, Mastercard) that facilitate the authentication process.

During a typical 3DS transaction, when a customer makes a purchase on a merchant's website, they are redirected to their card issuer's 3DS page for authentication. This step often involves entering a password, receiving a one-time passcode (OTP), or using biometric authentication. The transaction proceeds only after the cardholder is successfully authenticated.

3DS ensures an additional layer of security, as it helps verify that the person initiating the transaction is a legitimate cardholder. This extra layer has become increasingly important in e-commerce environments where fraud prevention is critical.

2. PCI DSS Requirement 6.4.3: Protecting Scripts on Payment Pages

PCI DSS Requirement 6.4.3 focuses on ensuring that unauthorized code or scripts cannot be executed on the payment page when it is rendered in the consumer's browser.

The objective of this requirement is to protect merchants and consumers from the introduction of malicious scripts that could lead to data breaches, such as Magecart-style attacks, which involve injecting malicious code into e-commerce sites to steal payment card details.

Specifically, Requirement 6.4.3 requires that any scripts running on the payment page of a merchant website must be authorized and must not have the capability to be modified without proper validation. This means that any third-party scripts or code loaded onto the payment page, which can interact with sensitive data, should be carefully vetted and controlled.

3. How Does PCI DSS Requirement 6.4.3 Apply to 3DS Scripts?

The use of 3DS scripts in online payment transactions typically occurs during the authentication process. In a standard 3DS implementation:

• The 3DS Server retrieves and stores URLs to scripts provided by an EMV 3DS Access Control Server (ACS) or an EMV 3DS Directory Server (DS), which are often connected to services representing card issuers or payment networks (Visa, Mastercard, etc.).
• During the checkout process, the merchant's website calls these scripts via an iframe, which is responsible for executing the 3DS functionality.

These 3DS scripts are critical for the 3DS authentication process. However, the FAQ clarifies that validation of PCI DSS Requirement 6.4.3 for 3DS scripts is not required, given the inherent trust relationship between the 3DS service provider and the merchant. This trust is established during the merchant's due diligence, onboarding, and business agreements with the 3DS service provider.

In simpler terms, because the merchant has vetted the 3DS service provider as part of their security assessments and legal agreements, the 3DS scripts are considered trustworthy and do not require additional validation under Requirement 6.4.3.

For more detailed information, refer to the official PCI SSC FAQ on this topic: How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page as part of 3DS processing?

4. Key Considerations for Merchants Using 3DS

While the FAQ exempts 3DS scripts from validation under Requirement 6.4.3, it is important to note that this exemption only applies to scripts directly related to the 3DS functionality. If a merchant uses any additional scripts on their payment page-scripts that fall outside the scope of 3DS processing-then those scripts must still comply with Requirement 6.4.3.

Key points to consider:

1. Trust in 3DS Service Providers: The relationship between merchants and their 3DS providers is critical. Due diligence must be conducted to ensure that the provider meets all PCI DSS requirements and that the business agreements clearly outline security responsibilities.
2. Limiting Scripts to 3DS Processing: Only scripts essential to the 3DS process should be executed during the checkout. Any script performing non-3DS functions should be treated according to PCI DSS 6.4.3, and its execution on the payment page should be restricted and controlled.
3. Preventing Unauthorized Code Execution: If any third-party scripts, aside from 3DS, are running on the payment page, merchants must ensure that these scripts are authorized, validated, and regularly reviewed to prevent unauthorized modifications that could lead to breaches.

5. Best Practices for Securing Scripts on Payment Pages

Even if 3DS scripts are exempt from PCI DSS Requirement 6.4.3 validation, ensuring that your checkout page is secure remains a top priority. Here are some best practices to follow:

• Regularly Vet Third-Party Providers: Conduct thorough due diligence on third-party providers (including 3DS providers) to ensure they adhere to security best practices.
• Restrict External Scripts: Limit the use of external scripts on your payment pages to minimize the attack surface. Ensure that only authorized and necessary scripts are executed during checkout.
• Script Integrity Checks: Implement Subresource Integrity (SRI) checks, which allow browsers to verify that third-party resources (like scripts) have not been tampered with.
• Content Security Policies (CSPs): Use Content Security Policies to control which scripts can be executed on your web pages. CSPs can restrict the sources from which scripts can be loaded, reducing the risk of malicious script injection.
• Regular Monitoring and Auditing: Continuously monitor the payment environment for any unauthorized changes or anomalies in the scripts running on checkout pages.

While PCI DSS Requirement 6.4.3 plays a crucial role in protecting merchants from unauthorized code execution, the nature of the 3DS protocol and the trust established between merchants and 3DS providers offer an exemption for 3DS-related scripts. However, this exemption only applies to scripts directly tied to the 3DS authentication process. Merchants should remain vigilant in securing any other scripts running on their payment pages and ensure that all third-party providers meet the necessary security standards.

By maintaining robust security controls, performing due diligence, and adhering to PCI DSS requirements, merchants can protect both themselves and their customers from online fraud and breaches.

For more insights into PCI DSS compliance and best practices, subscribe to our newsletter:

• Article Newsletter
• Video Materials
• Telegram Channel