--- description: A ready-to-run prompt that sets up Report URI CSP reporting on a Magento, Adobe Commerce or Mage-OS store, using the store's existing policy rather than deploying a new header. --- # Onboard your agent to Report URI on Magento You are an AI agent setting up **Report URI** CSP reporting on a **Magento 2, Adobe Commerce or Mage-OS** store. Follow the steps in order. Never invent credentials or endpoint addresses - always ask the user, or read the real values from the account. The canonical version of this prompt lives at . **Read this before you start.** Magento is not a generic web application, and the usual advice does not apply here: - **Do not add a `Content-Security-Policy` header yourself.** Magento already sends one. It has shipped the `Magento_Csp` module, enabled, since 2.3.5. Adding your own header in nginx, Apache or a template means two policies on the same response, and a browser enforces the intersection of both, so the store breaks in ways that are hard to trace. - **Do not use the Report URI CSP Wizard on this store.** The Wizard builds a Report URI policy from reports for you to deploy as a header. On Magento the policy is generated from `csp_whitelist.xml` across every installed module, so there is nowhere clean to deploy a Wizard-built policy. Collect against Magento's own policy instead, which is what the rest of this prompt does. - **Do not turn enforcement on.** Nothing here changes what the store blocks. If the user asks for enforcement, that is a separate job, done after reports have been collected for a while. The job is small: Magento is already generating violation reports and discarding them, because the field they should be delivered to ships empty. You are filling that field in. ## Step 1 - Connect the Report URI MCP server You need the account's real endpoint addresses, and they are unique per account. - **Endpoint:** `https://mcp.report-uri.com/` - **Auth:** `Authorization: Bearer ` Ask the user for their API key. If they do not have one, they create it at - **the full key is shown only once, at creation**. Personal keys start `ruri_d_`, team keys start `ruri_t_`, and only a team owner or admin can create a team's key. **Do not guess or fabricate a key.** **Claude Code:** ```bash claude mcp add --transport http report-uri https://mcp.report-uri.com/ --header "Authorization: Bearer ruri_d_YOUR_KEY_HERE" ``` For Claude Desktop, Cursor, VS Code and other clients, see . **Treat the key as a secret.** Some clients keep MCP config inside the repository (`.cursor/mcp.json`, `.vscode/mcp.json`), which puts the key one `git add` from being committed. Reference an environment variable or add the file to `.gitignore`, and confirm with `git check-ignore ` before staging anything. **MCP servers load at client startup**, so the tools are not available in this session yet. Have the user restart the client, then run this prompt again and skip to Step 2. Confirm with the `get_account_info` tool before continuing. **If the user will not or cannot connect MCP**, ask them to open and paste the **Report-Only** address from the CSP section. It looks like `https://SUBDOMAIN.report-uri.com/r/d/csp/reportOnly`. That single value is enough for Step 4. ## Step 2 - Confirm the store and its version Run these in the Magento root: ```bash bin/magento --version composer show | grep -E 'magento/product-|mage-os/product-|magento/module-csp' ``` Record the edition (Open Source, Adobe Commerce, Mage-OS) and the exact version. The version decides how many fields exist: - **2.4.7 and later**, or the backports **2.4.4-p9**, **2.4.5-p8**, **2.4.6-p6**: four reporting fields. Checkout and Admin Create Order **enforce** their policy; the storefront and Admin defaults stay report-only. Continue to Step 3. - **2.3.5 up to those versions**: only two fields, `storefront` and `admin`, both report-only. Everything below still works, you just set two values instead of four, and the module in Step 4 will refuse to install. Skip to Step 5 and set the two paths by hand. - **Before 2.3.5**: no `Magento_Csp` module. Nothing to configure. Tell the user and stop. Confirm the module is actually enabled: ```bash bin/magento module:status Magento_Csp ``` Also note the deploy mode, because it changes what you have to run afterwards: ```bash bin/magento deploy:mode:show ``` ## Step 3 - Read the account's real endpoint addresses Call the **`get_setup`** MCP tool. You need: - `reportUri.reportOnly` - ends in `/csp/reportOnly`, for the pages that only report. - `reportUri.enforce` - ends in `/csp/enforce`, for the two pages that enforce. **Use these two, not the Wizard endpoint**, for the reason given at the top of this prompt. The disposition matters. If enforced and report-only violations arrive on the same endpoint they are merged into one data set, and "this was blocked" becomes indistinguishable from "this would have been blocked". Those are very different facts on a checkout page. ## Step 4 - Install the module (preferred route) The module writes all four fields, gives each the disposition its page actually uses, and fixes a second problem you cannot fix from the Admin: Magento builds its `Report-To` header out of the CSP report URI, which is the wrong endpoint. Browsers that support the Reporting API prefer `report-to` and ignore `report-uri` entirely, so on an otherwise correct configuration those reports are posted somewhere that cannot accept them and are lost. Firefox and Safari keep working, which is why it looks like odd data rather than a broken setup. Check compatibility first - the module requires `magento/module-csp` at one of the versions in Step 2, and Composer will refuse the install otherwise. ```bash composer require report-uri/magento2-csp-reporting bin/magento module:enable ReportUri_CspReporting bin/magento setup:upgrade ``` In **production** deploy mode, also run: ```bash bin/magento setup:di:compile bin/magento setup:static-content:deploy ``` Then set the address. One value populates all four fields: ```bash bin/magento config:set csp/reporturi/address "https://SUBDOMAIN.report-uri.com/r/d/csp/reportOnly" bin/magento cache:flush ``` `config:set` goes through the same save path as the Admin form, so the module's backend model runs and derives the other endpoints from this one address. **Verify that it did** before moving on - if these come back empty, the write did not propagate and you should set the four paths directly as in Step 5: ```bash bin/magento config:show csp/mode/storefront/report_uri bin/magento config:show csp/mode/admin/report_uri bin/magento config:show csp/mode/storefront_checkout_index_index/report_uri bin/magento config:show csp/mode/admin_sales_order_create_index/report_uri ``` Check all four, not a sample. One address populates every field, so a partial result means the write did not propagate the way it should have, and two of these are Admin fields that would otherwise go uncollected without anything saying so. The first two should end `/csp/reportOnly`, the last two `/csp/enforce`. Two optional settings, both defaulting to on, both safe to leave alone: ```bash # Adds 'report-sample' to script-src, so reports carry the first 40 characters of # what was blocked. Sends no extra reports. bin/magento config:set csp/reporturi/report_sample 1 # Adds 'report-sha256' to script-src to enable CSP Integrity. bin/magento config:set csp/reporturi/report_hashes 1 ``` The module is MIT licensed and its source is at . It only ever acts on a Report URI address: if the store already points at a different collector, it leaves the configuration untouched. ## Step 5 - Or configure the fields by hand Use this if the module cannot be installed - an older version, a locked-down Composer setup, or the user simply prefers it. It gets the reports flowing; it does not fix the `Report-To` problem described in Step 4. ```bash # Report-only pages bin/magento config:set csp/mode/storefront/report_uri "https://SUBDOMAIN.report-uri.com/r/d/csp/reportOnly" bin/magento config:set csp/mode/admin/report_uri "https://SUBDOMAIN.report-uri.com/r/d/csp/reportOnly" # Enforcing pages - 2.4.7+, or 2.4.4-p9 / 2.4.5-p8 / 2.4.6-p6 only bin/magento config:set csp/mode/storefront_checkout_index_index/report_uri "https://SUBDOMAIN.report-uri.com/r/d/csp/enforce" bin/magento config:set csp/mode/admin_sales_order_create_index/report_uri "https://SUBDOMAIN.report-uri.com/r/d/csp/enforce" bin/magento cache:flush ``` The equivalent Admin path is **Stores > Configuration > Security > Content Security Policy > Mode**, with one **Report URI** field under each of Storefront Default, Storefront > One Page Checkout, Admin Default and Admin > Create Order. **Scope.** CSP configuration is store-scoped. Setting it at default scope covers every store view that has not overridden it, which is almost always what you want for a reporting endpoint. If the user runs a multi-store install and has overridden CSP config per website or store view, ask which scopes they want covered and add `--scope` and `--scope-code` to the commands above. ## Step 6 - Verify the headers are live ```bash curl -sI https://STORE_DOMAIN/ | grep -iE '^(content-security-policy|report-to|reporting-endpoints)' ``` Expected on the storefront home page: - `Content-Security-Policy-Report-Only` containing `report-uri` with the `/csp/reportOnly` address. - `Report-To` with the account's Reporting API address, which ends `/a/d/g` or `/a/t/g` - **not** the `/r/d/csp/...` one. If it carries the CSP address, the module is not active. Re-check Step 4. - `Reporting-Endpoints` naming a `default` group, if the module is installed. Then check the checkout, which should be an **enforcing** header on 2.4.7 and later: ```bash curl -sI https://STORE_DOMAIN/checkout/ | grep -i '^content-security-policy' ``` If nothing changed, the cache is the usual culprit: `bin/magento cache:flush`, and check any Varnish or CDN layer in front of the store. ## Step 7 - Confirm reports are arriving Call the **`get_reports`** MCP tool. Reports appear within a few minutes of real traffic. If nothing arrives after the headers verify correctly: - The store may have very little traffic. Load a few storefront pages yourself. - Check the account has quota left with **`get_quota_usage`**. - A `Report-To` header pointing at the CSP endpoint loses every Chromium report while Firefox and Safari keep working. If the reports you do see are all from Firefox and Safari, that is this problem exactly - go back to Step 4. **Do not enable enforcement**, and do not change any `report_only` setting. The user should watch the reports for a while first. ## What the user does next Explain these; do not do them. 1. **Their own violations.** Magento generates its policy from `csp_whitelist.xml` in each module. A resource the store legitimately uses that is missing from the whitelist shows up as a violation, and the fix is a `csp_whitelist.xml` entry in a custom module, not a wider policy. 2. **Third-party scripts.** Payment providers, tag managers and analytics all appear here. This is the script inventory PCI DSS 6.4.3 asks for on a payment page, built from what actually executed in real browsers. 3. **Change detection.** A script appearing on checkout that has never run there before is one of the earliest reliable signals of a skimmer, which is what PCI DSS 11.6.1 is asking for. 4. **Enforcement, later.** Once the reports are quiet and understood, moving checkout from report-only to enforced is a real decision with real risk. It is not part of this setup. ## Reference - Adobe Commerce and Magento guide: - The module: - Every documentation page as plain Markdown: ## Report back Print a short status summary: ``` Report URI on Magento --------------------- Magento version / edition ....... MCP server connected ............ yes / no Endpoints read (get_setup) ...... yes / no Module installed ................ yes / no (or: configured by hand) Four fields populated ........... yes / no Storefront header verified ...... yes / no Report-To on /a/ endpoint ....... yes / no (module only) Reports arriving (get_reports) .. yes / no Enforcement changed ............. no ```