Framework № PCI DSS 4.0.1 от 11.06.2024

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

Customized Approach Objective:
Unauthorized code cannot be executed in the payment page as it is rendered in the consumer’s browser. 

Applicability Notes:
This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties. 
This requirement also applies to scripts in the entity’s webpage(s) that includes a TPSP’s/ payment processor’s embedded payment page/form (for example, one or more inline frames or iframes). 
This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on its webpage. 
Scripts in the TPSP’s/payment processor’s embedded payment page/form are the responsibility of the TPSP/payment processor to manage in accordance with this requirement. 
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  

Defined Approach Testing Procedures:

Purpose:
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 ex-filtrate 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 minimizes the number of scripts that could be tampered with. 
Ensuring that scripts have been explicitly authorized reduces the probability of unnecessary scripts being added to the payment page without appropriate management approval. Where it is impractical for such authorization to occur before a script is changed or a new script is added to the page, the authorization should be confirmed as soon as possible after a change is made. 
Using techniques to prevent tampering with the script will minimize the probability of the script being modified to carry out unauthorized behavior, such as skimming the cardholder data from the payment page. 

Good Practice:
Scripts may be authorized 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 unauthorized content being substituted for the payment page. 
Where an entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage, the entity should expect the TPSP/payment processor to provide evidence that the TPSP/payment processor is meeting this requirement, in accordance with the TPSP’s/payment processor’s PCI DSS assessment and Requirement 12.9. 

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