Search intent: informational/procedural — Magento developers implementing Content Security Policy. We cover what CSP does, the skimmer threat model, report-only rollout, whitelist configuration, switching to enforcement, and ongoing maintenance. It builds on our Magento security checklist and patch guide.

Content Security Policy is an HTTP response header telling the browser which sources of script, style, image, font and connection are permitted. Anything outside the policy is blocked by the browser itself. Magento CSP has shipped as core functionality since Magento 2.3.5, with policies configurable separately for the storefront and admin areas.

The threat it addresses is specific and expensive. Magecart-style skimming attacks compromise a store — often through a vulnerable extension or unpatched core — and inject JavaScript into checkout that reads card fields and posts them to an attacker-controlled domain. Crucially, this happens client-side, so server-side scanning may not detect it, and customers see a normal checkout. With Magento CSP enforced, the injected script either cannot load (its source is not whitelisted) or cannot transmit (the destination is not permitted by connect-src). That is why CSP is the control that matters here: it breaks the attack even after a compromise.

The safe rollout order for Magento CSP is report-only first. Enforcing a policy before you know what your store legitimately loads will break payment iframes, analytics, chat widgets and your own theme JavaScript — usually discovered by customers at checkout. Report-only lets you collect the full picture without breaking anything.

Start by inventorying what the store loads: payment provider scripts and iframes, analytics and tag managers, chat and review widgets, font and CDN sources, and any inline scripts your theme or extensions emit. Then enable report-only and gather violations from the browser console and your report endpoint across real journeys — home, category, product, cart, checkout, and the admin.

# storefront: start in report-only (observe, block nothing)
bin/magento config:set system/csp/mode/storefront/report_only 1

# admin area, same approach
bin/magento config:set system/csp/mode/admin/report_only 1

bin/magento cache:flush

# check what the browser is actually receiving
curl -sI https://example.com/checkout/ | grep -i content-security-policy

Walk the whole purchase journey with the console open and log every violation. Expect more than you predict — third-party tags load other third-party tags, and those nested sources need whitelisting too. This inventory stage is the real work of a Magento CSP implementation.

Legitimate sources are declared in csp_whitelist.xml, placed in a module’s or theme’s etc/ directory (use etc/frontend/ or etc/adminhtml/ to scope a policy to one area). The correct practice for Magento CSP is to add these in your own module rather than editing core files, so the configuration survives upgrades and lives in version control.

<?xml version="1.0"?>
<csp_whitelist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <policies>
        <policy id="script-src">
            <values>
                <value id="payment_provider" type="host">js.paymentprovider.com</value>
                <value id="analytics" type="host">www.googletagmanager.com</value>
            </values>
        </policy>
        <policy id="connect-src">
            <values>
                <value id="payment_api" type="host">api.paymentprovider.com</value>
            </values>
        </policy>
        <policy id="frame-src">
            <values>
                <value id="payment_iframe" type="host">secure.paymentprovider.com</value>
            </values>
        </policy>
    </policies>
</csp_whitelist>

Two directives deserve particular attention in any Magento CSP policy. script-src controls what may execute — obviously central. But connect-src is what actually stops exfiltration: even if a skimmer runs, it cannot POST card data to a destination your policy does not permit. Teams often whitelist script sources carefully and leave connect-src permissive, which undermines the entire defence.

Once report-only runs clean across every journey, switch Magento CSP to restrict mode — this is where protection begins. Do it on staging first, walk the full purchase path including a real payment, then promote. Watch closely for the first days, because low-traffic pages and less-common payment methods surface violations that testing missed.

# report_only = 0  ->  policy is ENFORCED
bin/magento config:set system/csp/mode/storefront/report_only 0
bin/magento cache:flush

# confirm the enforcing header is present (not -Report-Only)
curl -sI https://example.com/checkout/ | grep -i "content-security-policy"

Maintenance is where most Magento CSP implementations quietly decay. Every new marketing tag, payment method or extension may introduce a new source that the policy blocks — so CSP has to become part of your change process, not a one-off project. Keep the report endpoint active even in enforce mode so you see what is being blocked, and review those reports: a sudden violation from an unfamiliar domain is exactly the signal CSP exists to give you. That signal is genuinely valuable, and worth more than the initial rollout. The MDN CSP reference and Adobe’s Commerce CSP documentation cover directives and module configuration in full. Our Magento team runs CSP rollouts end to end.