Magento & CSP: the ultimate guide

To comply with the upcoming PCI DSS requirements, Adobe has added CSP and SRI support in Magento and Adobe Commerce. With the recent Magento 2.4.7 release, CSP is set to strict mode in the checkout, and the CSP module cannot be disabled anymore. This update breaks checkouts all over the world. What should you do?

Broken checkouts

A strict CSP may block inline Javascript and third party libraries, so upgrading to one of the following versions will likely break your checkout.

• Magento 2.4.7 and up
• Magento 2.4.6-p6
• Magento 2.4.5-p8
• Magento 2.4.4-p9

Adobe published a comprehensive guide to troubleshoot legacy code. However, if your code comes from an external vendor (like with most stores), you'll have to wait for the vendor to provide fixes. In the meantime, we recommend to disable "strict CSP" on checkout 👇

Disable strict CSP on checkout

While 2.4.7 is set to "strict" by default, you can set it to "report-only" mode.

Some guides recommend to edit vendor/magento/module-checkout/etc/config.xml but this may get overwritten after a new release. So it is better to update your config in env.php. The following will set enable report-only for the checkout and admin routes. It also enables inline scripts (not PCI compliant per Apr 2025!).

<?php
return [
    [...]
    'system' => [
        'default' => [
            'csp' => [
               'mode' => [
                  'storefront_checkout_index_index' => [
                     'report_only' => '1'
                  ],
                  'admin_sales_order_create_index' => [
                    'report_only' => '1'
                  ]
               ],
               'policies' => [
                  'storefront_checkout_index_index' => [
                    'scripts' => [
                        'inline' => '1'
                    ]
                  ],
                  'admin_sales_order_create_index' => [
                    'scripts' => [
                        'inline' => '1'
                    ]
                  ]
               ]
            ]
        ]
    ]
];

Then, run:

bin/magento app:config:import
bin/magento cache:clean config

Now your whole site is running in report-only mode. Legacy code will no longer be blocked and any violations will be reported in the console. Of course, you should resolve this before April 2025. But, how to identify the problems?

Collecting CSP reports in Magento

While you could just monitor the developer console yourself, you don't know what is happening in your customer's browsers. Luckily CSP has a nifty feature that will instruct all browsers to report problems on an external address. You can build such a report collector yourself, or use the free one provided by Sansec: ⇒ CSP monitoring for Magento. It will give you a clear and live overview in just a few minutes.

CSP and PCI compliance

For anyone dealing with credit card payments, PCI DSS compliance is essential. Even if you use a third party payment provider. From April 1, 2025, PCI DSS will require implementing CSP on pages that handle payment processing to enhance security. Proper CSP implementation helps in safeguarding payment data against injection attacks and is a step towards PCI compliance.

Benefits of CSP

When CSP is properly configured, it can:

• send alerts for unauthorized new javascript sources
• send alerts for data leaks
• provide an inventory overview of all code elements in your store

Problems with CSP

CSP isn't the holy grail against web skimming though, here are a couple issues. Still, it's one of the best tools available to us, since it is supported by all major browsers.

Hefty maintenance required

Raw CSP requires a lot of investment and maintenance. Even with a collection endpoint up and running, you will have to deal with lots of noise from broken browsers, rogue extensions and other alerts that have nothing to do with your store.

That's where Smart CSP Monitoring such as Sansec Watch comes in. Because Sansec Watch aggregates public data from thousands of stores around the world, it can filter out the noise and present you relevant, actionable alerts only.

Google Analytics 4 with Google Signals

Using CSP with location-based trust does not work well with Google Analytics 4 (GA4) if you have enabled Google Signals. If you use GA4 with Signals on your checkout, you need to add all of the local Google domains to your accept list, which is possible but increases the header size and may slow down your store. So far, Google does not want to change this behavior and tells people to use strict-dynamic with nonces instead. However, that method is incompatible with Magento. So you either have large HTTP headers, or cannot use Google Signals (used to track logged-in users across devices).

3D Secure via iframe

Some payment services, notably Paypal's Braintree (read saga here), are embedded using an iframe. When a card payment requires 3D Secure verification, the payment service will redirect the visitor in the iframe to their own bank. Because there are many banks in this world, it is not possible to add all of them to a CSP allow-list. Paypal therefore recommends to disable CSP protection for the iframe by adding a frame-src * policy. You should be aware that this probably doesn't pass PCI DSS requirements, as an attacker could abuse this to insert their own iframe location.

Payments-giant Adyen states:

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.

CSP protection can be bypassed

CSP wasn't specifically designed to protect against digital skimming (instead, to protect against XSS attacks). While it is certainly useful, there are a number of ways to bypass it.

• If one of the trusted sites has a JSONP or AngularJS endpoint, it can be used to inject arbitrary Javascript.
• Given the complexity of the CSP protocol, it is easy to make a configuration error. And an attacker only needs a single mistake in the policy.
• If the backend code is compromised, an attacker could tamper with the CSP header, or add a hash or nonce to their own malware.
• Random browser extensions generate lots of CSP violation reports, leading to report fatigue. Or extensions may mangle your requests leading to false reports.
• Common browsers limit the number of CSP violation reports to 100 per page. Because a typical Magento installation has many more elements, CSP monitoring gives an incomplete view.

Magento & directive hierarchy

Within the Magento CSP system, any plugin can define its own policies. However, this may pose a problem when one module defines a policy for script-src-elem and another one for script-src. Because browsers don't automatically merge policies, they will take the most strict one script-src-elem, effectively ignoring the script-src policies. Not all extension vendors are aware of this, so you should test your new CSP policy with a proper monitoring tool. Psst: Sansec provides a free CSP monitor for Magento to identify such problems.

Magento & strict-dynamic

Will Magento support strict-dynamic, which is the Gooogle-recommended way to use CSP? As of May 2024, Adobe stated that there are no specific plans to do so at the moment (despite mention in the architecture docs).

What shall I do?

Not using CSP yet? While it isn't perfect, it would stop 95% of all frontend skimming attacks. So we recommend to enable CSP as soon as possible. Set it up for report-only and connect a suitable CSP monitoring service, such as the free Sansec Watch. It will filter the noise and alert you to new or modified script elements. Because Sansec runs a huge database of eCommerce malware, we will also alert you to any malicious activity.

See also

• Adobe: troubleshooting CSP checkout errors
• Adobe Commerce docs on CSP
• Bug: 2.4.5-p8 changed to strict
• 2.4.5 release notes on CSP and SRI