Blog · Magento 2

csp_whitelist.xml Not Working in Magento 2? Troubleshooting Guide

You added a csp_whitelist.xml file, ran setup:upgrade, deployed, and the storefront is still blocking the exact host you whitelisted. This is a common enough problem that it’s worth walking through the usual causes in order, since the fix is almost always one of these five things.

1. The module isn’t registered or enabled
2. Cache wasn’t cleared
3. Wrong scope — frontend vs adminhtml vs global
4. The directive name doesn’t match
5. A theme or module override is stripping your entry

1. The module isn’t registered or enabled

csp_whitelist.xml only takes effect if it lives in etc/ (or etc/frontend/) inside a module that’s actually registered and enabled. Check:

bin/magento module:status Vendor_ModuleName

If it’s not in the enabled list, run:

bin/magento module:enable Vendor_ModuleName
bin/magento setup:upgrade

A surprising number of “the whitelist doesn’t work” cases are actually “the module was never enabled.”

2. Cache wasn’t cleared — specifically config and full page cache

CSP policy generation is cached. A setup:upgrade alone doesn’t guarantee the new policy is being served. Run:

bin/magento cache:flush config
bin/magento cache:flush full_page

If you’re testing on a store using Varnish or a CDN in front of Magento, flush that layer too — it may be serving a cached response with the old headers.

3. Wrong scope — frontend vs adminhtml vs global

csp_whitelist.xml files can live under etc/, etc/frontend/, or etc/adminhtml/. A file placed in etc/adminhtml/ only affects the Admin panel’s own CSP, not the storefront — a very easy mistake when you’re trying to fix a storefront error. Storefront rules need to be in etc/frontend/csp_whitelist.xml (or etc/csp_whitelist.xml for global scope).

4. The directive name doesn’t match what’s actually being violated

Check the exact directive named in the browser console error — it’s easy to whitelist script-src when the actual violation is on connect-src or frame-src. Third-party services frequently need two or three directives covered (see the Stripe and GTM CSP guides for examples of services needing multiple directives at once), and whitelisting only one of them will still show blocked requests for the others.

5. A theme or module override is stripping your entry

If you’re on a multi-store setup, check whether a different csp_whitelist.xml at a more specific scope (store view) is overriding rather than merging with your entry. Magento merges policies by directive across scopes, but a conflicting type for the same id can cause unexpected results. Renaming your id attributes to be unique across all files in the project avoids this class of bug entirely.

Confirming what Magento is actually sending

The most reliable way to debug this isn’t to keep editing XML and re-deploying — it’s to look at the actual response header. In DevTools, open the Network tab, reload the page, click the document request, and check the Content-Security-Policy (or Content-Security-Policy-Report-Only) response header directly. If your host isn’t in there, the XML isn’t being picked up for that scope — go back to steps 1–3.

A faster way to check this without redeploying

Because each of these issues usually means another deploy-and-check cycle, this is one of the more time-consuming parts of Magento CSP work. CSP Manager for Magento adds a CSP Policy Inspector screen under Admin that shows the exact merged policy per store view — every directive, every value, and whether it came from Magento’s XML or an Admin-managed rule. That turns “is my host actually in the policy” from a DevTools-and-deploy exercise into a one-screen check, and lets you add or correct a rule directly from Admin without a new deploy if the fix is just a missing host.