Magento & Adobe Commerce

Your Magento store already sends CSP reports. Nowhere.

Every Magento 2 install ships a Content-Security-Policy-Report-Only header that is turned on by default. The field those reports are meant to be delivered to ships empty. Four Admin fields, no code, and you get the script inventory PCI DSS 6.4.3 asks for.

Start 30-Day Free Trial See what your store is already doing
The Default Nobody Chose

Reports are being generated right now. They have nowhere to go.

Magento 2 has shipped the Magento_Csp module since 2.3.5, and it is enabled out of the box. The storefront and the Admin both send a report-only policy, which means every browser that loads a page builds a violation report for anything outside that policy — and then finds no endpoint to send it to.

The reporting endpoint is a separate setting, and its default is empty. Nobody turned this off. It arrived that way, and on most stores it has stayed that way through every upgrade since.

What a stock Magento storefront sends today
Content-Security-Policy-Report-Only: default-src 'self' https: ...
  script-src 'self' 'unsafe-inline' 'unsafe-eval' https: ...

(no report-uri directive, no report-to directive)

The control is deployed. The evidence is being thrown away.

Proof

This is not a handful of stores

We crawl the top million sites and record what security headers they actually send. In the August 2026 crawl, 2,568 of those sites were taking card payments behind a report-only CSP with no reporting endpoint anywhere in the policy.

2,236 of those 2,568 are Magento

87% of every payment-taking site we found with this exact misconfiguration runs on one platform. That is not 2,236 independent decisions — it is a platform default reaching its logical conclusion.

And the top million is the small end of it

Store Leads counts over 100,000 live Magento stores. The crawl only sees the ones big enough to rank, so the population carrying this default is far larger than the sample we can measure directly.

If you want to check your own store before reading any further: load your storefront, open developer tools, and look at the response headers for Content-Security-Policy-Report-Only. If it has no report-uri in it, this page is about you.

Which Pages Enforce

Since 2.4.7, your checkout is different from the rest of your store

This catches people out on upgrade, so it is worth being precise about. Two pages enforce their policy; everything else reports only.

Page Default mode Set by
Storefront — everything else Report-only Magento_Csp
Admin — everything else Report-only Magento_Csp
Storefront — One Page Checkout Restrict Magento_Checkout
Admin — Create Order Restrict Magento_Sales

Those two enforcing pages also drop 'unsafe-inline' from script-src. An inline script that was merely noisy before the upgrade stops running afterwards — and with no reporting endpoint set, nothing tells you it happened.

The Fix

Four fields in the Admin. No code, no extension.

Go to Stores > Configuration > Security > Content Security Policy > Mode. Each of the four groups has a single Report URI field. They are URL-validated, so paste the full endpoint including the scheme.

Because checkout enforces while the rest of the storefront only reports, a single endpoint across all four mixes enforced violations and report-only violations into one data set. Set them separately and the two stay readable:

Admin field Endpoint to paste
Storefront Default https://abc123.report-uri.com/r/d/csp/reportOnly
Storefront > One Page Checkout https://abc123.report-uri.com/r/d/csp/enforce
Admin Default https://abc123.report-uri.com/r/d/csp/reportOnly
Admin > Create Order https://abc123.report-uri.com/r/d/csp/enforce

abc123 is your own subdomain, which you will find on the Setup page in your account. A page-specific field left empty falls back to the default for its area, so the two defaults alone are enough to start collecting.

Filling in a reporting endpoint does not change what your policy permits. A store on the report-only default blocks nothing before you do this and blocks nothing after. What changes is that you can see what it would have caught.

Start Free Trial Read the full Magento guide →
Why This Matters For PCI

Your checkout is a payment page in the sense PCI DSS 4.0 means it

Requirements 6.4.3 and 11.6.1 apply to the page that takes the card. Magento already enforces a policy there. What it does not do is keep any record of what that policy saw.

6.4.3 — script authorisation and inventory

Every script on the payment page must be known, approved and documented. Reports from real browsers give you an inventory of what actually executed — including scripts a third-party extension injected that nobody documented.

11.6.1 — change detection

Changes to payment page scripts and to the security headers themselves must be detected and acted on. Continuously, not at your next assessment.

Magento gives you the control. The reporting endpoint is what turns it into evidence an assessor can read.

How the requirements map → What non-compliance costs →
The Threat

Magento is the platform Magecart was named after

Card skimming groups target Magento specifically, and they have done for years. The attack does not need a vulnerability in your code — an unpatched extension, a compromised third-party script, or an admin session is enough to get a few lines of JavaScript onto the checkout page. From there the skimmer reads the card fields directly out of the DOM as the customer types.

A CSP report is one of the earliest reliable signals that this has happened: a script appearing on a page it has never run on before, or data heading for a destination that was never authorised. That signal is being generated on your store today and discarded before anyone sees it.

Script Watch
Req 6.4.3 — script inventory and change detection

Every script on the checkout, including the ones an extension added

New script, modified script, unauthorised dependency — flagged against an inventory built from real page loads rather than from asking around.

Learn more about Script Watch →
Policy Watch
Req 11.6.1 — change detection on the control itself

Extensions edit csp_whitelist.xml. You should know when they do.

Third-party Magento extensions ship their own csp_whitelist.xml entries, which widen your policy on install without asking. Policy Watch monitors the deployed header and tells you the moment it changes.

Learn more about Policy Watch →
Data Watch
Req 11.6.1 — behavioural monitoring

Where checkout data is going

Detects when data starts leaving your checkout for somewhere it should not. Destinations, anomalies, and a behavioural record — which is what a skimmer looks like before anyone reports a fraudulent charge.

Learn more about Data Watch →

Read how CosmicSting was used against Magento stores →

Get Started

Reports arrive on the next page load

Create an account, copy your endpoint from the Setup page, and paste it into the four Admin fields. Flush the cache and the reports your store has been discarding start arriving instead. Nothing of ours runs on your storefront and there is no extension to install.

Four fields. No code. Live in under an hour.

Running this across a portfolio of client stores? Talk to our team →

FAQ

Frequently asked questions

Yes. Every Magento 2 install from 2.3.5 onwards ships the Magento_Csp module, and it is on. The storefront and the Admin both send Content-Security-Policy-Report-Only, so every visitor's browser is already generating violation reports. What ships empty is the field those reports are supposed to be sent to, which means the browser builds each report and then has nowhere to deliver it.

No. The four fields already exist in the Admin under Stores > Configuration > Security > Content Security Policy. Paste your endpoint into them and reports start arriving on the next page load. There is no code to write and nothing of ours executes on your store.

From 2.4.7, One Page Checkout on the storefront and Create Order in the Admin enforce, and everything else stays report-only. Those two pages also drop 'unsafe-inline' from script-src. Because the modes differ, point the two enforcing pages at your enforce endpoint and the two defaults at reportOnly, or enforced and report-only violations arrive mixed into one data set.

No. The reporting endpoint is where reports are delivered; it has no bearing on what the policy permits. A store on the report-only default blocks nothing before you fill the field in and blocks nothing after. What changes is that you can see what the policy would have caught.

Your checkout is a payment page in the sense PCI DSS 4.0 means it. 6.4.3 asks you to inventory and authorise every script on that page; 11.6.1 asks you to detect changes to those scripts and to the page headers. Reports from real browsers give you an inventory built from what actually executed, and change detection on top of it. See our PCI DSS guide for how the requirements map to the evidence.

CSP configuration is store-scoped, so check which scope you are editing before you save. A value set at default scope applies to every store view that has not overridden it, which is usually what you want for the reporting endpoint.

All three editions ship the same Magento_Csp module and configure it identically, so everything here applies to Adobe Commerce, Magento Open Source and Mage-OS alike.

Yes. The same values live under csp/mode/{area}/report_uri in a custom module's etc/config.xml, with per-page overrides using Magento's full action name. Our Adobe Commerce and Magento guide has the XML.

Your store has been generating this evidence all along.

It takes four fields to stop throwing it away.

Start 30-Day Free Trial