CSP Report Analyzer
Group CSP violation reports and separate enforced blocks from report-only signals.
Accepts legacy csp-report payloads, Reporting API csp-violation objects, JSON arrays, and one-report-per-line NDJSON.
How should the report set be read?
Query redaction applies to known URL fields. Original policy text can still contain an endpoint URL, and samples can contain page content.
Copyable analysis
The grouped CSP analysis will appear here.
A violation report is evidence, not an allowlist request
A CSP report says that a browser encountered activity outside a policy. With an enforced policy, that activity was blocked. With a report-only policy, the browser reported what would have been blocked. Neither case means the blocked source should automatically be added to the policy.
Extension-injected scripts, stale pages, third-party widgets, experiments, compromised code, and genuine application dependencies can all create reports. Grouping repeated events helps separate a one-off signal from something that deserves investigation.
Legacy report-uri and Reporting API payloads are not identical
Legacy delivery wraps fields inside csp-report and commonly arrives as application/csp-report. Newer Reporting API delivery uses report objects whose type is csp-violation, places CSP fields inside body, and uses application/reports+json for server delivery.
The normalizer accepts both shapes without pretending they contain exactly the same metadata. Missing disposition is left unknown instead of being guessed.
The blocked value may be a keyword or a shortened URL
Values such as inline, eval, data:, or blob: are meaningful CSP signals even though they are not ordinary resource URLs. Browsers can also reduce a cross-origin blocked URL to its origin to avoid leaking path information.
That is why the cross-origin count compares origins only when both the document and blocked values can be parsed as HTTP(S) URLs. It does not label every different hostname as an unsafe third party.
Treat report content as untrusted input
Violation reports can contain URLs and, when 'report-sample' is enabled for the relevant directive, a short sample of inline script, handler, or style content. Report collectors should store and render those fields as untrusted data rather than HTML.
Query-string redaction reduces accidental leakage when sharing an analysis, but it cannot scrub secrets embedded in paths, policy text, custom log fields, or samples. Read the copied output before posting it to an issue tracker or chat.
What to look for before moving from report-only to enforcement
- Repeated violations from application code you actually intend to run.
- Inline code that can be removed or covered with a nonce or hash rather than a broad source.
- HTTP resources that should be upgraded to HTTPS instead of permitted as mixed content.
- Cross-origin dependencies whose ownership, necessity, and failure behavior are understood.
- Important user paths that have been exercised long enough to expose realistic policy gaps.
The specifications behind these fields
CSP Level 3 defines the violation body and the difference between enforced and report-only disposition. The Reporting API defines report envelopes, endpoint delivery, and the application/reports+json format. The older report-uri mechanism remains relevant for compatibility even though CSP Level 3 marks that directive deprecated.
References: Content Security Policy Level 3 and Reporting API.