Managing Payment Scripts according to PCI DSS v 4.0

On our Data security page in Adyen’s documentation, you can find recommendations for securing your Customer Area accounts, integration, and backend implementation according to PCI DSS.

You can read the compliance guide in Adyen's documentation for general information on PCI DSS programs. It discusses the importance and implications of PCI DSS compliance for all card payment flows and your responsibilities when integrating with Adyen solutions.

Being non-compliant with PCI DSS requirements might increase your chance of having a data breach in your environment and being subject to card scheme assessments.

The following guide provides recommendations to help you comply with PCI DSS v4.0 requirements for web applications accepting payments. Since Adyen has limited visibility of your cardholder data environment, this document only provides general guidance. You can always consult with a PCI DSS-certified third party to ensure you are compliant.

The new PCI DSS v4.0 requirements includes some new requirements that are future-dated, such as Requirements 6.4.3, which will go into effect on March 31, 2025. This requirement is to control how your payment pages manage scripts that are loaded. It states:

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 justification as to why each is necessary.

This applies to online payment web integrations (Web Drop-in, Components, and API-only). We load some scripts for specific payment methods if you’re using our Web Drop-in or Components.

Authorizing scripts

We recommend that you implement a Content Security Policy (CSP) because it lets you authorize scripts before loading them on a page. You can modify the CSP in your page header to allow all internally loaded scripts by default and expressly allow scripts from non-internal domains to be loaded.

In this walk-through, we cover the steps to build your CSP and test it without breaking your site in the process.

Report-only CSP HTTP header

Let’s start with the report-only CSP header. This type of header causes no issues with how your integration functions because it does not block any resources from loading.

After implementing it, you can see what violations come up when you visit your site.

First, add the following HTTP header to your page:

You now have a report-only policy that tells the browser:

• default-src: use this policy if resources are not defined in the other sections.

• font-src: defines what fonts may be loaded.

• img-src: defines what images may be loaded.

• script-src: defines what scripts may be loaded.

• style-src: defines what styles/css may be loaded.

The first argument (default-src) is called a directive. All the directives in the example have 'self' as a trusted source, which tells the browser to only load resources hosted on the same domain/subdomain.

Next, let’s allow resources that are loaded from external sources.

Allowing scripts from external sources

Your CSP header can allow either:

• Anything (like images, scripts, media, etc.) to be loaded from an external domain/subdomain.

• Only selected things that you specify to be loading from an external domain/subdomain.

Let’s start with an example header that allows anything. In the example below, we allow loading resources from our own domain/subdomain and resources that come from the trusted domain *.example.com:

Now, let’s create an example that’s a bit stricter. In the example below, we allow loading the following:

• default-src 'self': resources from our own domain/subdomain.

• img-src images.com: only images from the domain images.com.

• script-src: only scripts from myscripts.otherwebsite.com.

Images and scripts that are loaded from other domains violate this policy and are included in the report:

Lastly, let’s create an example with the scripts that Drop-in and Components use:

Possible issues with CSP

Blocking resources from external domains can cause issues with 3D Secure 2 authentication. The resources in the iframe element that shows the authentication interface is loaded from the Access Control Server (ACS). Adyen does not and is not responsible for maintaining a list of ACS URLs.

If you choose to implement a CSP header that blocks resources from loading, you must ensure that you include the list of ACS URLs used for 3D Secure 2 authentication so that the authentication interface can load.

Useful tools for creating and testing a CSP

• https://csper.io/generator

• https://csp-evaluator.withgoogle.com/

Checking the integrity of scripts

We recommend that you implement Subresource Integrity (SRI) to ensure that the files you are loading from Adyen haven’t been manipulated by or tampered with by malicious actors.

To use the SRI hash, add the integrity attribute when specifying <script> or <link> elements. Browsers also check for the crossorigin attribute to ensure that the origin allows Cross-Origin Resource Sharing (CORS). If a browser detects that the file's hash does not match the specified hash, the browser doesn’t load the resource. You can find out which browsers support SRI on this browser compatibility list.

Adyen provides the SRI hash that you include as the integrity attribute. You can find the SRI hashes for all versions of our JavaScript and CSS files in the release notes in our documentation, under Updating to this version.

Here’s an example of how to specify version 5.59.1 adyen.js and adyen.css resources:

You must keep a list of scripts that load on your website with the reason for each script. The following scripts are the ones that Web Drop-in and Components loads from third parties:

Depending on your integration, this may not be the full list of scripts that are loaded on your site.

Last updated: May 8, 2024

We’ve provided you with a few things you can do to keep your website that accepts payments compliant:

• Creating a CSP header

• Adding scripts from third-party domains to the allow list

• SRI verification

Keep in mind that these recommendations are just a few ways you can start getting your integration ready for the PCI DSS v4.0 script security requirements. There might be different controls you need to implement depending on your payment environment to meet the requirements.

We recommend always staying up-to-date with PCI DSS requirements and consulting with a professional if you can not maintain compliance in-house.