Read four fields first: blockedURL, effectiveDirective, documentURL and disposition. Together they say what was blocked, by which rule, on which page, and whether the policy was enforced or only reported. Known vendor domains on expected pages are noise to tune. Unknown domains on checkout are the ones to chase.
Where the report comes from
A Content Security Policy can send reports to an endpoint you control. MDN says the recommended method is the Reporting API: declare endpoints in the Reporting-Endpoints header, then name one in the report-to directive of your policy. The older report-uri directive still works and sends a slightly different JSON format.
When the report arrives it is a JSON object whose type is csp-violation. MDN's example includes these fields in the body.
| Field | What it tells you |
|---|---|
| blockedURL | The resource that was blocked. A value of inline means an inline script or style |
| effectiveDirective | The rule that blocked it, for example script-src-elem |
| documentURL | The page where it happened |
| disposition | enforce if the policy blocked it, report if it only reported |
| sourceFile, lineNumber, columnNumber | Where in the code the attempt came from |
| sample | A short sample of the code, where provided |
| referrer | The page the visitor came from |
| originalPolicy | The policy text that applied |
Sorting reports into three piles
- Known and wanted. A vendor you approved, on a page where it belongs, blocked because your policy forgot it. Fix the policy.
- Known and unwanted. A vendor you meant to remove, still loading. Remove the tag. See how to find script tags left behind by old vendors.
- Unknown. A domain nobody recognizes, especially on cart, checkout or account pages. Treat it as an incident until proven otherwise.
Browser extensions on a visitor's own device can cause blocked-resource reports too, so a single odd report from one visitor is weaker evidence than the same domain across many.
What to watch for on a store
- A new blockedURL on checkout that was never in your tag register.
- A sudden rise in inline violations after a release or a tag manager publish.
- Reports with the same sourceFile across many visitors.
- Violations whose documentURL is a page that should have no third-party code at all.
Run it in report-only mode first
MDN describes the Content-Security-Policy-Report-Only header as a way to monitor violations without enforcing the policy, so you can test or repair violations before a policy is enforced. The report-to directive must be set for reports to be sent, or the header has no effect. The header is not supported inside a meta element. Read our step by step report-only rollout for the full plan.
Keep the volume manageable
Reports can pile up on a busy store. Group by blockedURL and effectiveDirective, count per day, and alert on new combinations rather than on every event. Review the top of the list weekly and the new entries daily during a rollout.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers the packages in your build. CSP reports are run-time signals from the browser, handled by your own endpoint and tooling. A free scan is at gold.safeguard.sh/scan.
Quick check
What does disposition report mean?
The policy was in report-only mode, so the resource was reported but not blocked.
Is every blocked URL an attack?
No. Many are missing allowlist entries or browser extensions. Unknown domains on checkout deserve a quick look.
Sources
Last reviewed: 19 October 2026.
