Content Security Policy (CSP) & Card betalingen

In juni 2024 publiceerde PCI een nieuwe versie (4.0.1) en vanaf april 2025 is deze versie actief.

De impact voor webshops die card betalingen accepteren binnen de eigen checkout is groot. Benieuwd naar de impact van PCI 4.0.1 voor jouw webshop?

Lees het artikel PCI DSS voor uitleg over wat PCI is.

Lees de volledige Engelstalige paragraaf 6.4.3 van het Requirements and Testing Procedures

Defined Approach Requirements

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 authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.

Customized Approach Objective

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

Defined Approach Testing Procedures

• Examine policies and procedures to verify that processes are defined for managing all payment page scripts that are loaded and executed in the consumer’s browser, in accordance with all elements specified in this requirement.

• Interview responsible personnel and examine inventory records and system configurations to verify that all payment page scripts that are loaded and executed in the consumer’s browser are managed in accordance with all elements specified in this requirement.

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 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 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.

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.

Applicability Notes

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:
• 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.

Wat is een Content Security Policy / CSP

Een CSP is een technische security standaard die er voor zorgt dat in de browser alleen scripts worden uitgevoerd die vooraf zijn vastgelegd. Dit voorkomt dat er onwenselijke scripts uitgevoerd worden.

Wat is het gevaar van geen Content Security Policy / CSP in een webshop?

Dit is een voorbeeld wat er in de praktijk in webshops gebeurd die geen CSP hebben:
1. Een hacker krijgt toegang tot de webshop en voegt een script toe.
2. Dit script voegt creditcard velden toe aan de checkout en stuurt de betaler naar de betaalprovider om daar nogmaals de creditcard gegevens in te voeren (waardoor de betalen doorgaat en niemand iets doorheeft).
3. De betaler vult creditcard gegevens in, de hacker laat deze naar zichzelf sturen.

Samengevat zijn de aandachtspunten voor webshops:

Aandachtspunt	Toelichting
Zorg dat je een webshop een Content Security Policy heeft.	Ook als de betaler de kaartgegevens bij de betaalprovider invult. Want zodra een kwaadwillige deze op jouw webshop laat invullen valt je webshop in scope van PCI
Zorg voor een overzicht van de toegestane scripts	Voor Magento webshops is Sansec Watch een goede keuze. Deze gebruiken de standaard report functionaliteit van Magento om een overzicht te maken, te beheren en vervolgens in Magento te voorkomen dat ze ingeladen worden.
Zorg dat je zo min mogelijk scripts gebruikt	Dit voorkomt een te grote header. Als voorbeeld, Magento laadt standaard erg veel scripts in. Dit beperken is aan te raden om het beheersbaar en snel te houden. Veel extensie's laden scripts in (die ze ook toevoegen aan de CSP) maar niet relevant zijn. Als voorbeeld, betaalproviders laden bijvoorbeeld Google Pay scripts in terwijl deze niet aan staat.