{"title":"Script security for ecommerce","category":"default","creationDate":1779620072,"content":"<p>PCI DSS v4.0.1 includes requirements for merchants to manage the risks associated with the scripts and <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTML\/Element\/iframe\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">iframe elements<\/a> loaded into their ecommerce payment pages. These requirements are for Web online payments integrations.<\/p>\n<p>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.<\/p>\n<p>When creating these recommendations, Adyen considered implementations advised by the <a href=\"https:\/\/www.pcisecuritystandards.org\/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">PCI Security Standards Council (PCI SSC)<\/a> in their formal guidance document: <a href=\"https:\/\/blog.pcisecuritystandards.org\/new-information-supplement-payment-page-security-and-preventing-e-skimming\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">Payment Page Security and Preventing E-Skimming - Guidance for PCI DSS Requirements 6.4.3 and 11.6.1<\/a>.<\/p>\n<h2>Requirements<\/h2>\n<p>Before you begin, check if the information on this page applies to you.<\/p>\n<table>\n<thead>\n<tr>\n<th style=\"text-align: left;\">Requirement<\/th>\n<th style=\"text-align: left;\">Description<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"text-align: left;\"><strong>Integration type<\/strong><\/td>\n<td style=\"text-align: left;\">The information on this page is relevant if any of the following apply to you: <ul><li>You complete the Self-Assessment Questionnaire D (SAQ D).<\/li> <li>You complete an Attestation of Compliance (AoC) for Onsite Assessment.<\/li> <li>You are an Adyen for Platforms partner.<\/li> <li>You are a partner that implements Adyen plugins.<\/li><\/ul><\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: left;\"><strong>Limitations<\/strong><\/td>\n<td style=\"text-align: left;\">The information on this page does <strong>not apply<\/strong> if you are <a href=\"\/development-resources\/pci-dss-compliance-guide\/saq-a-eligibility\">eligible for Self-Assessment Questionnaire A (SAQ A)<\/a>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>PCI DSS requirement 6.4.3<\/h2>\n<p>Requirement 6.4.3 mandates that all payment page scripts that are loaded and executed in the consumer\u2019s browser are managed as follows:<\/p>\n<ul>\n<li>A method is implemented to confirm that each script is authorized.<\/li>\n<li>A method is implemented to assure the integrity of each script.<\/li>\n<li>An inventory of all scripts is maintained with written justification as to why each is necessary.<\/li>\n<\/ul>\n<h3>Exemption for 3D Secure authentication scripts<\/h3>\n<p>In a typical 3D Secure implementation, the 3D Secure server fetches and stores URLs for scripts from an <a href=\"https:\/\/www.emvco.com\/emv-technologies\/3-d-secure\/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">EMV 3DS<\/a> 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.<\/p>\n<p>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.<\/p>\n<h2>PCI DSS requirement 11.6.1<\/h2>\n<p>Requirement 11.6.1 mandates that a change- and tamper-detection mechanism is deployed as follows:<\/p>\n<ul>\n<li>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 <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Document_Object_Model\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">Document Object Model (DOM)<\/a> throughout the payment process.<\/li>\n<li>It evaluates the received HTTP headers and payment pages.<\/li>\n<li>Any unauthorized changes must be investigated and resolved promptly.<\/li>\n<\/ul>\n<h2>Implement a Content Security Policy for requirement 6.4.3<\/h2>\n<p>To comply with PCI DSS requirement 6.4.3, we recommend that you implement a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Content_Security_Policy\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">Content Security Policy (CSP)<\/a> on your payment page to authorize and assure the integrity of scripts.<\/p>\n<p>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:<\/p>\n<ul>\n<li>Allow all internally-loaded scripts by default.<\/li>\n<li>Expressly allow scripts from non-internal domains to be loaded.<\/li>\n<\/ul>\n<p>Additionally, we provide guidance on the options for reporting and alerting from your implemented CSP.<\/p>\n<p>To ensure the integrity of scripts, we recommend implementing <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/Security\/Subresource_Integrity\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">Subresource Integrity (SRI)<\/a> to confirm that the files you load from Adyen have not been manipulated or tampered with by malicious actors.<\/p>\n<p>To build a CSP, consider the following recommendations:<\/p>\n<ul>\n<li><a href=\"#report-only-header\">Use a report-only CSP HTTP header<\/a>.<\/li>\n<li><a href=\"#allow-external-sources\">Allow scripts an iframes from external sources<\/a>.<\/li>\n<li><a href=\"#scripts-inventory\">Create an inventory of scripts<\/a>.<\/li>\n<li><a href=\"#scripts-integrity\">Check the integrity of scripts<\/a>.<\/li>\n<\/ul>\n<h3 id=\"report-only-header\">Use a report-only CSP HTTP header<\/h3>\n<p>This type of header causes no issues with how your integration works because it does not block any resources from loading.<\/p>\n<div class=\"notices green\">\n<p>By using the <code>Content-Security-Policy-Report-Only<\/code> header instead of the <code>Content-Security-Policy<\/code> header, the browser only logs the violation. It does not block any content from being loaded.<\/p>\n<\/div>\n<p>Add the following HTTP header to your page.<\/p>\n<div data-component-wrapper=\"code-sample\">\n    <code-sample :title=\"'Report-only header'\" :id=\"''\" :code-data=\"[{&quot;language&quot;:&quot;bash&quot;,&quot;tabTitle&quot;:&quot;&quot;,&quot;content&quot;:&quot;Content-Security-Policy-Report-Only: default-src 'self'; font-src 'self'; img-src 'self'; script-src 'self'; style-src 'self'&quot;}]\" :enable-copy-link-to-code-block=\"true\" :code-sample-card-size=\"'fullsize'\"><\/code-sample>\n<\/div>\n<p>After you implement it, you can see the violations that show up when visiting your website. The report-only policy shows you the following.<\/p>\n<table>\n<thead>\n<tr>\n<th>Field<\/th>\n<th>Description<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><code>default-src<\/code><\/td>\n<td>This <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/Reference\/Headers\/Content-Security-Policy\/script-src\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">CSP directive<\/a> tells the browser which domains or subdomains scripts may be loaded from. <br> In all of our examples, we use <span translate=\"no\"><strong>'self'<\/strong><\/span> as a trusted source, telling the browser to only load resources that are hosted on the same domain or subdomain. <br> If sources are not defined in any other directives, they apply this default policy.<\/td>\n<\/tr>\n<tr>\n<td><code>font-src<\/code><\/td>\n<td>What fonts may be loaded.<\/td>\n<\/tr>\n<tr>\n<td><code>img-src<\/code><\/td>\n<td>What images may be loaded.<\/td>\n<\/tr>\n<tr>\n<td><code>script-src<\/code><\/td>\n<td>What scripts may be loaded.<\/td>\n<\/tr>\n<tr>\n<td><code>style-src<\/code><\/td>\n<td>What styles\/css may be loaded.<\/td>\n<td><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3 id=\"allow-external-sources\">Allow scripts and iframes from external sources<\/h3>\n<p>Your CSP header can allow either of the following:<\/p>\n<ul>\n<li>Anything, like images, scripts, media, and more, to be loaded from an external domain or subdomain.<\/li>\n<li>Only things that you specify to be loaded from an external domain or subdomain.<\/li>\n<\/ul>\n<p>We recommend that you implement the following blocking policy.<\/p>\n<ol>\n<li>\n<p>Change the header to <code>Content-Security-Policy<\/code>. This is a blocking policy. You can add some defined exemptions.<\/p>\n<\/li>\n<li>\n<p>Allow specific domains and subdomains. When you define specific sources for scripts (<code>script-src<\/code>) and iframes (<code>frame-src<\/code>) they only allow loading resources from the specified domains, and everything else is blocked.<\/p>\n<p>For Adyen integrations, we recommend that you apply the following CSP configuration:<\/p>\n<div data-component-wrapper=\"code-sample\">\n<code-sample :title=\"'Recommended CSP configuration'\" :id=\"''\" :code-data=\"[{&quot;language&quot;:&quot;bash&quot;,&quot;tabTitle&quot;:&quot;&quot;,&quot;content&quot;:&quot;Content-Security-Policy:\\n\\ndefault-src 'self';\\nscript-src: *.adyen.com pay.google.com *.payments-amazon.com *.paypal.com *.ratepay.com *.cash.app\\nfont-src: cash-f.squarecdn.com\\nstyle-src: *.cash.app\\n\\nframe-src: *\\nimg-src: *\\nconnect-src:*\\nform-action:*&quot;}]\" :enable-copy-link-to-code-block=\"true\" :code-sample-card-size=\"'fullsize'\"><\/code-sample>\n<\/div>\n<p>If you have other third party integrations loading additional scripts, you must explicitly add them to the <code>script-src<\/code> directive.<\/p>\n<\/li>\n<\/ol>\n<p>Scripts and images that are loaded from other domains violate this policy and are included in the <a href=\"#report\">report that you configure for the CSP<\/a>.<\/p>\n<p>We suggest that you use the wildcard (<bold>*<\/bold>) for the iframe elements in this policy, for the following reasons:<\/p>\n<ul>\n<li>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.<\/li>\n<li>Not using any <code>frame-src<\/code> definition might be functional but not stable. It would lead the CSP to use the default value, which is usually defined as blocking <span translate=\"no\"><strong>none<\/strong><\/span>. 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.<\/li>\n<li>\n<p>This recommended implementation could allow any iframes to be loaded. However, iframes from Adyen are <a href=\"https:\/\/en.wikipedia.org\/wiki\/Sandbox_(computer_security)\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">sandboxed<\/a> and iframes that come from 3DS issuer banks are also sandboxed. By sandboxing, issues such as <a href=\"https:\/\/en.wikipedia.org\/wiki\/Cross-site_scripting\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">cross-site scripting<\/a> are prevented, not adding any additional risk.<\/p>\n<div class=\"notices green\">\n<p>Web <a href=\"https:\/\/www.geeksforgeeks.org\/what-is-browser-sandboxing\/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">Browser Sandboxing<\/a> 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.<\/p>\n<\/div>\n<\/li>\n<\/ul>\n<h3 id=\"scripts-inventory\">Create an inventory of scripts<\/h3>\n<p>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.<\/p>\n<p>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 <a href=\"#report\">change is reported<\/a>.<\/p>\n<p>Adyen loads scripts from the following domain sources. Include them in your inventory for your Adyen integration:<\/p>\n<table>\n<thead>\n<tr>\n<th>Source<\/th>\n<th>Description<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>*.adyen.com<\/td>\n<td>Adyen-authorized domain for scripts loaded for payment-processing-associated services.<\/td>\n<\/tr>\n<tr>\n<td>pay.google.com<\/td>\n<td>Allows integration with the Google Pay payment method.<\/td>\n<\/tr>\n<tr>\n<td>*.payments-amazon.com<\/td>\n<td>Allows integration with the Amazon Pay payment method.<\/td>\n<\/tr>\n<tr>\n<td>*.paypal.com<\/td>\n<td>Allows integration with the PayPal payment method.<\/td>\n<\/tr>\n<tr>\n<td>*.ratepay.com<\/td>\n<td>Allows integration with the Ratepay payment method.<\/td>\n<\/tr>\n<tr>\n<td>*.cash.app<\/td>\n<td>Allows integration with the Cash App service.<\/td>\n<\/tr>\n<tr>\n<td>*.mastercard.com<\/td>\n<td>Allows integration with Click to Pay using Mastercard.<\/td>\n<\/tr>\n<tr>\n<td>*.visa.com<\/td>\n<td>Allows integration with Click to Pay using Visa.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3 id=\"scripts-integrity\">Check the integrity of scripts<\/h3>\n<p>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.<\/p>\n<ol>\n<li>To the <code>&lt;script&gt;<\/code> or <code>&lt;link&gt;<\/code>elements, add the <code>integrity<\/code> attribute.<\/li>\n<li>\n<p>Add the <code>crossorigin<\/code> attribute. Browsers also check to ensure that the origin allows <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/CORS\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">Cross-Origin Resource Sharing (CORS)<\/a>. If the browser detects that the file's hash does not match the specified hash, the browser does not load the resource. Find out <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/Security\/Subresource_Integrity#Browser_compatibility\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">which browsers support SRI<\/a>.<\/p>\n<p>For each version of Adyen Web Drop-in\/Components, we provide the SRI hashes that you include as the <code>integrity<\/code> attribute for the JavaScript and CSS files. In the <a href=\"\/online-payments\/release-notes\/?title%5B0%5D=Web%2BComponents%2FDrop-in\">release notes, go to the <strong>Updating to this version<\/strong> section<\/a> for the version that you use.<\/p>\n<p>The following example shows how include SRI hashes for the <code>adyen.js<\/code> and <code>adyen.css<\/code> resources for v5.59.1:<\/p>\n<div data-component-wrapper=\"code-sample\">\n<code-sample :title=\"'SRI hashes for v5.59.1'\" :id=\"''\" :code-data='[{\"language\":\"javascript\",\"tabTitle\":\"\",\"content\":\"&lt;script src=\\\"https:\\\/\\\/checkoutshopper-live.adyen.com\\\/checkoutshopper\\\/sdk\\\/5.59.0\\\/adyen.js\\\"\\n  integrity=\\\"sha384-O8p0CLZyOw1jkmYN7ZwJxWzd+sDYRFGpLEffqc+dKye24gFImbU72did4PC7ysTY\\\"\\n  crossorigin=\\\"anonymous\\\"&gt;&lt;\\\/script&gt;\\n\\n&lt;link rel=\\\"stylesheet\\\"\\n  href=\\\"https:\\\/\\\/checkoutshopper-live.adyen.com\\\/checkoutshopper\\\/sdk\\\/5.59.0\\\/adyen.css\\\"\\n  integrity=\\\"sha384-zgFNrGzbwuX5qJLys75cOUIGru\\\/BoEzhGMyC07I3OSdHqXuhUfoDPVG03G+61oF4\\\"\\n  crossorigin=\\\"anonymous\\\"&gt;\"}]' :enable-copy-link-to-code-block=\"true\" :code-sample-card-size=\"'fullsize'\"><\/code-sample>\n<\/div>\n<\/li>\n<\/ol>\n<h2>Implement detection mechanisms for requirement 11.6.1<\/h2>\n<p>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.<\/p>\n<p>You must collect all CSP alerts in a practical manner. You can do this by implementing the <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/Reference\/Headers\/Content-Security-Policy\/report-to\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\"><code>report-to<\/code> directive<\/a>, 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\".<\/p>\n<p><a id=\"report\"><\/a><\/p>\n<ol>\n<li>\n<p>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 <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/CSPViolationReportBody\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">CSPViolationReportBody<\/a> object instance. Using the mechanisms of the <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Reporting_API\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">Reporting API<\/a>, the browser sends the report to your endpoint URL.<\/p>\n<\/li>\n<li>\n<p>Specify the mapping between endpoint names and URLs by adding the <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/Reference\/Headers\/Reporting-Endpoints\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\"><code>Reporting-Endpoints<\/code> response header<\/a> to your CSP. You can use any name for your endpoints.<\/p>\n<div data-component-wrapper=\"code-sample\">\n<code-sample :title=\"'Example of Reporting-Endpoints response header'\" :id=\"''\" :code-data='[{\"language\":\"bash\",\"tabTitle\":\"\",\"content\":\"Reporting-Endpoints: your_endpoint_name=\\\"https:\\\/\\\/example.com\\\/csp-reports\\\"\"}]' :enable-copy-link-to-code-block=\"true\" :code-sample-card-size=\"'fullsize'\"><\/code-sample>\n<\/div>\n<\/li>\n<li>\n<p>Add <code>report-to<\/code>, specifying the endpoint URL on your server that you want the browser to use for reporting CSP violations.<\/p>\n<div data-component-wrapper=\"code-sample\">\n<code-sample :title=\"'Example of report-to directive'\" :id=\"''\" :code-data='[{\"language\":\"bash\",\"tabTitle\":\"\",\"content\":\"report-to your_endpoint_name\"}]' :enable-copy-link-to-code-block=\"true\" :code-sample-card-size=\"'fullsize'\"><\/code-sample>\n<\/div>\n<\/li>\n<li>\n<p>When a CSP violation occurs, you get a <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/Reference\/Headers\/Content-Security-Policy\/report-to#violation_report_syntax\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" class=\"external-link no-image\">report with CSP violations<\/a>.<\/p>\n<\/li>\n<\/ol>\n<h2>See also<\/h2>\n<p>Have a look at the following PCI DSS resources:<\/p>\n<div class=\"see-also-links output-inline\" id=\"see-also\">\n<ul><li><a href=\"https:\/\/blog.pcisecuritystandards.org\/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a\"\n                        target=\"_blank\"\n                         class=\"external\">\n                    Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A\n                <\/a><\/li><li><a href=\"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\/\"\n                        target=\"_blank\"\n                         class=\"external\">\n                    How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page as part of 3DS processing?\n                <\/a><\/li><\/ul><\/div>\n","url":"https:\/\/docs.adyen.com\/development-resources\/pci-dss-compliance-guide\/script-security","articleFields":{"description":"Implement script security on your ecommerce payment page to comply with PCI DSS v4.0.1 requirements.","feedback_component":true,"filters_component":false,"decision_tree":"[]"},"algolia":{"url":"https:\/\/docs.adyen.com\/development-resources\/pci-dss-compliance-guide\/script-security","title":"Script security for ecommerce","content":"PCI DSS v4.0.1 includes requirements for merchants to manage the risks associated with the scripts and iframe elements loaded into their ecommerce payment pages. These requirements are for Web online payments integrations.\nThis 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.\nWhen creating these recommendations, Adyen considered implementations advised by the PCI Security Standards Council (PCI SSC) in their formal guidance document: Payment Page Security and Preventing E-Skimming - Guidance for PCI DSS Requirements 6.4.3 and 11.6.1.\nRequirements\nBefore you begin, check if the information on this page applies to you.\n\n\n\nRequirement\nDescription\n\n\n\n\nIntegration type\nThe 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.\n\n\nLimitations\nThe information on this page does not apply if you are eligible for Self-Assessment Questionnaire A (SAQ A).\n\n\n\nPCI DSS requirement 6.4.3\nRequirement 6.4.3 mandates that all payment page scripts that are loaded and executed in the consumer\u2019s browser are managed as follows:\n\nA method is implemented to confirm that each script is authorized.\nA method is implemented to assure the integrity of each script.\nAn inventory of all scripts is maintained with written justification as to why each is necessary.\n\nExemption for 3D Secure authentication scripts\nIn a typical 3D Secure implementation, the 3D Secure server fetches and stores URLs for scripts from an EMV 3DS 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.\nThe 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.\nPCI DSS requirement 11.6.1\nRequirement 11.6.1 mandates that a change- and tamper-detection mechanism is deployed as follows:\n\nIt 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) throughout the payment process.\nIt evaluates the received HTTP headers and payment pages.\nAny unauthorized changes must be investigated and resolved promptly.\n\nImplement a Content Security Policy for requirement 6.4.3\nTo comply with PCI DSS requirement 6.4.3, we recommend that you implement a Content Security Policy (CSP) on your payment page to authorize and assure the integrity of scripts.\nA 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:\n\nAllow all internally-loaded scripts by default.\nExpressly allow scripts from non-internal domains to be loaded.\n\nAdditionally, we provide guidance on the options for reporting and alerting from your implemented CSP.\nTo ensure the integrity of scripts, we recommend implementing Subresource Integrity (SRI) to confirm that the files you load from Adyen have not been manipulated or tampered with by malicious actors.\nTo build a CSP, consider the following recommendations:\n\nUse a report-only CSP HTTP header.\nAllow scripts an iframes from external sources.\nCreate an inventory of scripts.\nCheck the integrity of scripts.\n\nUse a report-only CSP HTTP header\nThis type of header causes no issues with how your integration works because it does not block any resources from loading.\n\nBy 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.\n\nAdd the following HTTP header to your page.\n\n    \n\nAfter you implement it, you can see the violations that show up when visiting your website. The report-only policy shows you the following.\n\n\n\nField\nDescription\n\n\n\n\ndefault-src\nThis CSP directive 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.\n\n\nfont-src\nWhat fonts may be loaded.\n\n\nimg-src\nWhat images may be loaded.\n\n\nscript-src\nWhat scripts may be loaded.\n\n\nstyle-src\nWhat styles\/css may be loaded.\n\n\n\n\nAllow scripts and iframes from external sources\nYour CSP header can allow either of the following:\n\nAnything, like images, scripts, media, and more, to be loaded from an external domain or subdomain.\nOnly things that you specify to be loaded from an external domain or subdomain.\n\nWe recommend that you implement the following blocking policy.\n\n\nChange the header to Content-Security-Policy. This is a blocking policy. You can add some defined exemptions.\n\n\nAllow 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.\nFor Adyen integrations, we recommend that you apply the following CSP configuration:\n\n\n\nIf you have other third party integrations loading additional scripts, you must explicitly add them to the script-src directive.\n\n\nScripts and images that are loaded from other domains violate this policy and are included in the report that you configure for the CSP.\nWe suggest that you use the wildcard (*) for the iframe elements in this policy, for the following reasons:\n\nAdyen 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.\nNot 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.\n\nThis recommended implementation could allow any iframes to be loaded. However, iframes from Adyen are sandboxed and iframes that come from 3DS issuer banks are also sandboxed. By sandboxing, issues such as cross-site scripting are prevented, not adding any additional risk.\n\nWeb 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.\n\n\n\nCreate an inventory of scripts\nFollowing 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.\nFurthermore, 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.\nAdyen loads scripts from the following domain sources. Include them in your inventory for your Adyen integration:\n\n\n\nSource\nDescription\n\n\n\n\n*.adyen.com\nAdyen-authorized domain for scripts loaded for payment-processing-associated services.\n\n\npay.google.com\nAllows integration with the Google Pay payment method.\n\n\n*.payments-amazon.com\nAllows integration with the Amazon Pay payment method.\n\n\n*.paypal.com\nAllows integration with the PayPal payment method.\n\n\n*.ratepay.com\nAllows integration with the Ratepay payment method.\n\n\n*.cash.app\nAllows integration with the Cash App service.\n\n\n*.mastercard.com\nAllows integration with Click to Pay using Mastercard.\n\n\n*.visa.com\nAllows integration with Click to Pay using Visa.\n\n\n\nCheck the integrity of scripts\nWe 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.\n\nTo the &lt;script&gt; or &lt;link&gt;elements, add the integrity attribute.\n\nAdd the crossorigin attribute. Browsers also check to ensure that the origin allows Cross-Origin Resource Sharing (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.\nFor 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 for the version that you use.\nThe following example shows how include SRI hashes for the adyen.js and adyen.css resources for v5.59.1:\n\n\n\n\n\nImplement detection mechanisms for requirement 11.6.1\nWe 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.\nYou must collect all CSP alerts in a practical manner. You can do this by implementing the report-to directive, 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\".\n\n\n\nCreate 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 object instance. Using the mechanisms of the Reporting API, the browser sends the report to your endpoint URL.\n\n\nSpecify the mapping between endpoint names and URLs by adding the Reporting-Endpoints response header to your CSP. You can use any name for your endpoints.\n\n\n\n\n\nAdd report-to, specifying the endpoint URL on your server that you want the browser to use for reporting CSP violations.\n\n\n\n\n\nWhen a CSP violation occurs, you get a report with CSP violations.\n\n\nSee also\nHave a look at the following PCI DSS resources:\n\n\n                    Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A\n                \n                    How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page as part of 3DS processing?\n                \n","type":"page","locale":"en","boost":17,"hierarchy":{"lvl0":"Home","lvl1":"Development resources","lvl2":"PCI DSS compliance guide","lvl3":"Script security for ecommerce"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/","lvl1":"https:\/\/docs.adyen.com\/development-resources","lvl2":"https:\/\/docs.adyen.com\/development-resources\/pci-dss-compliance-guide","lvl3":"\/development-resources\/pci-dss-compliance-guide\/script-security"},"levels":4,"category":"Development Resources","category_color":"green","tags":["Script","security","ecommerce"]}}