---
title: "Script security for ecommerce"
description: "Implement script security on your ecommerce payment page to comply with PCI DSS v4.0.1 requirements."
url: "https://docs.adyen.com/development-resources/pci-dss-compliance-guide/script-security"
source_url: "https://docs.adyen.com/development-resources/pci-dss-compliance-guide/script-security.md"
canonical: "https://docs.adyen.com/development-resources/pci-dss-compliance-guide/script-security"
last_modified: "2026-06-01T15:33:16+02:00"
language: "en"
---

# Script security for ecommerce

Implement script security on your ecommerce payment page to comply with PCI DSS v4.0.1 requirements.

[View source](/development-resources/pci-dss-compliance-guide/script-security.md)

PCI DSS v4.0.1 includes requirements for merchants to manage the risks associated with the scripts and [iframe elements](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) loaded into their ecommerce payment pages. These requirements are for Web online payments integrations.

This page gives a brief overview of the specific PCI DSS v4.0.1 requirements related to script security, and provides recommendations for how to comply with these requirements.

When creating these recommendations, Adyen considered implementations advised by the [PCI Security Standards Council (PCI SSC)](https://www.pcisecuritystandards.org/) in their formal guidance document: [Payment Page Security and Preventing E-Skimming - Guidance for PCI DSS Requirements 6.4.3 and 11.6.1](https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming).

## Requirements

Before you begin, check if the information on this page applies to you.

| Requirement          | Description                                                                                                                                                                                                                                                                                                     |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Integration type** | The information on this page is relevant if any of the following apply to you:- You complete the Self-Assessment Questionnaire D (SAQ D).
- You complete an Attestation of Compliance (AoC) for Onsite Assessment.
- You are an Adyen for Platforms partner.
- You are a partner that implements Adyen plugins. |
| **Limitations**      | The information on this page does **not apply** if you are [eligible for Self-Assessment Questionnaire A (SAQ A)](/development-resources/pci-dss-compliance-guide/saq-a-eligibility).                                                                                                                           |

## PCI DSS requirement 6.4.3

Requirement 6.4.3 mandates that 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.

### Exemption for 3D Secure authentication scripts

In a typical 3D Secure implementation, the 3D Secure server fetches and stores URLs for scripts from an [EMV 3DS](https://www.emvco.com/emv-technologies/3-d-secure/) Access Control Server (ACS), EMV 3DS Directory Server (DS), or services connected to the ACS or DS, on behalf of an issuer or payment network. During checkout, your website shows a web page with an iframe using a URL provided by the EMV 3DS server with an applicable script to support 3D Secure functionality.

The 3D Secure script validation process is exempted from the scope of PCI DSS requirement 6.4.3, because the trust relationship with the 3D Secure service provider is established through due diligence, onboarding, and business agreements of the entities involved.

## PCI DSS requirement 11.6.1

Requirement 11.6.1 mandates that a change- and tamper-detection mechanism is deployed as follows:

* It alerts personnel about unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security impacting HTTP headers and the script contents of payment pages, as received by the consumer browser's [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) throughout the payment process.
* It evaluates the received HTTP headers and payment pages.
* Any unauthorized changes must be investigated and resolved promptly.

## Implement a Content Security Policy for requirement 6.4.3

To comply with PCI DSS requirement 6.4.3, we recommend that you implement a [Content Security Policy (CSP)](https://en.wikipedia.org/wiki/Content_Security_Policy) on your payment page to authorize and assure the integrity of scripts.

A CSP allows you to authorize scripts before loading them on your page. You can modify the CSP in your page header to do the following:

* Allow all internally-loaded scripts by default.
* Expressly allow scripts from non-internal domains to be loaded.

Additionally, we provide guidance on the options for reporting and alerting from your implemented CSP.

To ensure the integrity of scripts, we recommend implementing [Subresource Integrity (SRI)](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) to confirm that the files you load from Adyen have not been manipulated or tampered with by malicious actors.

To build a CSP, consider the following recommendations:

* [Use a report-only CSP HTTP header](#report-only-header).
* [Allow scripts an iframes from external sources](#allow-external-sources).
* [Create an inventory of scripts](#scripts-inventory).
* [Check the integrity of scripts](#scripts-integrity).

### Use a report-only CSP HTTP header

This type of header causes no issues with how your integration works because it does not block any resources from loading.

By using the `Content-Security-Policy-Report-Only` header instead of the `Content-Security-Policy` header, the browser only logs the violation. It does not block any content from being loaded.

Add the following HTTP header to your page.

**Report-only header**

```bash
Content-Security-Policy-Report-Only: default-src 'self'; font-src 'self'; img-src 'self'; script-src 'self'; style-src 'self'
```

After you implement it, you can see the violations that show up when visiting your website. The report-only policy shows you the following.

| Field         | Description                                                                                                                                                                                                                                                                                                                                                                                                                                           |   |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - |
| `default-src` | This [CSP directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src) tells the browser which domains or subdomains scripts may be loaded from. In all of our examples, we use **'self'** as a trusted source, telling the browser to only load resources that are hosted on the same domain or subdomain. If sources are not defined in any other directives, they apply this default policy. |   |
| `font-src`    | What fonts may be loaded.                                                                                                                                                                                                                                                                                                                                                                                                                             |   |
| `img-src`     | What images may be loaded.                                                                                                                                                                                                                                                                                                                                                                                                                            |   |
| `script-src`  | What scripts may be loaded.                                                                                                                                                                                                                                                                                                                                                                                                                           |   |
| `style-src`   | What styles/css may be loaded.                                                                                                                                                                                                                                                                                                                                                                                                                        |   |

### Allow scripts and iframes from external sources

Your CSP header can allow either of the following:

* Anything, like images, scripts, media, and more, to be loaded from an external domain or subdomain.
* Only things that you specify to be loaded from an external domain or subdomain.

We recommend that you implement the following blocking policy.

1. Change the header to `Content-Security-Policy`. This is a blocking policy. You can add some defined exemptions.

2. Allow specific domains and subdomains. When you define specific sources for scripts (`script-src`) and iframes (`frame-src`) they only allow loading resources from the specified domains, and everything else is blocked.

   For Adyen integrations, we recommend that you apply the following CSP configuration:

   **Recommended CSP configuration**

   ```bash
   Content-Security-Policy:

   default-src 'self';
   script-src: *.adyen.com pay.google.com *.payments-amazon.com *.paypal.com *.ratepay.com *.cash.app
   font-src: cash-f.squarecdn.com
   style-src: *.cash.app

   frame-src: *
   img-src: *
   connect-src:*
   form-action:*
   ```

   If you have other third party integrations loading additional scripts, you must explicitly add them to the `script-src` directive.

Scripts and images that are loaded from other domains violate this policy and are included in the [report that you configure for the CSP](#report).

We suggest that you use the wildcard (\*) for the iframe elements in this policy, for the following reasons:

* Adyen loads only 3D Secure (3DS) authentication iframes. According to the PCI SSC, the 3DS script validation process is exempted from the scope of PCI DSS Requirement 6.4.3, because the trust relationship with the 3DS service provider is established through due diligence, onboarding, and business agreements of the entities involved. Because it is not possible to list all issuer domains loading iframes for 3DS authentication, a more stringent CSP might block 3DS iframes from loading.

* Not using any `frame-src` definition might be functional but not stable. It would lead the CSP to use the default value, which is usually defined as blocking **none**. Therefore, some definition needs to be made. With our recommended CSP header setup, we make it possible to use CSP, but still allow loading all 3DS iframes which are exempted from the requirements.

* This recommended implementation could allow any iframes to be loaded. However, iframes from Adyen are [sandboxed](https://en.wikipedia.org/wiki/Sandbox_\(computer_security\)) and iframes that come from 3DS issuer banks are also sandboxed. By sandboxing, issues such as [cross-site scripting](https://en.wikipedia.org/wiki/Cross-site_scripting) are prevented, not adding any additional risk.

  Web [Browser Sandboxing](https://www.geeksforgeeks.org/what-is-browser-sandboxing/) allows running web applications in isolation to prevent browser-based malware from spreading to the rest of the webpage or network. Most modern browsers already have a sandbox by default to enhance the protection of the user's computer.

### Create an inventory of scripts

Following PCI DSS Requirement 6.4.3, all scripts added to your page must be in an inventory. This means that you must keep a list, including the ones required for Adyen integrations, with the business reason to use them.

Furthermore, you must have a simple periodical authorization sign-off. Ensuring that all scripts have been explicitly authorized reduces the risk of unnecessary scripts being added to the payment page without appropriate approval. However, for some cases, it can be impractical for such authorization to occur before a script is changed or a new script is loaded to the page. In these cases, the authorization should be confirmed as soon as a [change is reported](#report).

Adyen loads scripts from the following domain sources. Include them in your inventory for your Adyen integration:

| Source                 | Description                                                                            |
| ---------------------- | -------------------------------------------------------------------------------------- |
| \*.adyen.com           | Adyen-authorized domain for scripts loaded for payment-processing-associated services. |
| pay.google.com         | Allows integration with the Google Pay payment method.                                 |
| \*.payments-amazon.com | Allows integration with the Amazon Pay payment method.                                 |
| \*.paypal.com          | Allows integration with the PayPal payment method.                                     |
| \*.ratepay.com         | Allows integration with the Ratepay payment method.                                    |
| \*.cash.app            | Allows integration with the Cash App service.                                          |
| \*.mastercard.com      | Allows integration with Click to Pay using Mastercard.                                 |
| \*.visa.com            | Allows integration with Click to Pay using Visa.                                       |

### Check the integrity of scripts

We recommend implementing Subresource Integrity (SRI) to ensure that the files you load from Adyen have not been manipulated or tampered with by malicious actors. Use the SRI hash by doing the following.

1. To the `<script>` or `<link>`elements, add the `integrity` attribute.

2. Add the `crossorigin` attribute. Browsers also check to ensure that the origin allows [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). If the browser detects that the file's hash does not match the specified hash, the browser does not load the resource. Find out [which browsers support SRI](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity#Browser_compatibility).

   For each version of Adyen Web Drop-in/Components, we provide the SRI hashes that you include as the `integrity` attribute for the JavaScript and CSS files. In the [release notes, go to the **Updating to this version** section](/online-payments/release-notes/?title%5B0%5D=Web%2BComponents%2FDrop-in) for the version that you use.

   The following example shows how include SRI hashes for the `adyen.js` and `adyen.css` resources for v5.59.1:

   **SRI hashes for v5.59.1**

   ```javascript
   <script src="https://checkoutshopper-live.adyen.com/checkoutshopper/sdk/5.59.0/adyen.js"
     integrity="sha384-O8p0CLZyOw1jkmYN7ZwJxWzd+sDYRFGpLEffqc+dKye24gFImbU72did4PC7ysTY"
     crossorigin="anonymous"></script>

   <link rel="stylesheet"
     href="https://checkoutshopper-live.adyen.com/checkoutshopper/sdk/5.59.0/adyen.css"
     integrity="sha384-zgFNrGzbwuX5qJLys75cOUIGru/BoEzhGMyC07I3OSdHqXuhUfoDPVG03G+61oF4"
     crossorigin="anonymous">
   ```

## Implement detection mechanisms for requirement 11.6.1

We recommend that you use your CSP implementation to comply with PCI DSS requirement 11.6.1. A functional CSP implementation can provide authorization and alerting in case of attempts to introduce unknown scripts or changes to currently authorized scripts. These events are considered valid alerts and "indicators of compromise" for the purpose of requirement 11.6.1.

You must collect all CSP alerts in a practical manner. You can do this by implementing the [`report-to` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/report-to), which sends you a report of alerts. This can help to meet the requirements included in 11.6.1, such as "alerting personnel of unauthorized modification".

[]()

1. Create an endpoint on your server you want the browser to use for reporting CSP violations. If a CSP violation occurs, a report is generated. It contains a serialized [CSPViolationReportBody](https://developer.mozilla.org/en-US/docs/Web/API/CSPViolationReportBody) object instance. Using the mechanisms of the [Reporting API](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API), the browser sends the report to your endpoint URL.

2. Specify the mapping between endpoint names and URLs by adding the [`Reporting-Endpoints` response header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Reporting-Endpoints) to your CSP. You can use any name for your endpoints.

   **Example of Reporting-Endpoints response header**

   ```bash
   Reporting-Endpoints: your_endpoint_name="https://example.com/csp-reports"
   ```

3. Add `report-to`, specifying the endpoint URL on your server that you want the browser to use for reporting CSP violations.

   **Example of report-to directive**

   ```bash
   report-to your_endpoint_name
   ```

4. When a CSP violation occurs, you get a [report with CSP violations](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/report-to#violation_report_syntax).

## See also

Have a look at the following PCI DSS resources:

* [Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a)
* [How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page as part of 3DS processing?](https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/how-does-pci-dss-requirement-6-4-3-apply-to-3ds-scripts-called-from-a-merchant-check-out-page-as-part-of-3ds-processing/)
