Why it matters
Rolling out a Content Security Policy in report-only mode is the right move, but it produces a flood of reports: thousands of JSON blobs, most of them from browser extensions, password managers and translation tools injecting their own scripts. The few that matter, a payment script you forgot or an inline snippet from your analytics, get lost, and teams either give up or loosen the policy until the reports stop.
This analyser reads both report formats, sorts out the noise (extension URLs, browser-internal sources, software that injects scripts into every page), and groups the rest by directive and source origin. Each group gets a recommendation that keeps the policy tight: allow a specific origin, give an inline script a nonce or hash, or remove the eval() call rather than adding 'unsafe-eval'. The additions are merged into your current policy using the same parser as the CSP evaluator. Reports stay on your device.
How it works
- InputCSP reports and your current policy
- In your browserNoise filtered, the rest grouped by directive and source
- OutputA fix per group and a merged policy
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Directive | Source | Reports |
|---|---|---|
| script-src-elem | https://js.stripe.com | 2 |
| img-src | data: | 2 |
| script-src-elem | inline | 1 |
| font-src | https://fonts.gstatic.com | 1 |
| script-src | eval | 1 |
| connect-src | https://region1.google-analytics.com | 1 |
How to use it
- Export or copy the reports your endpoint has collected.
- Paste them, along with your current policy.
- Ignore the noise, read the grouped violations and their fixes.
- Copy the proposed policy and test it in report-only mode.
FAQ
Why are there so many reports from extensions?
Extensions inject scripts and styles into the pages you visit, and your policy blocks them like any other source. You can't fix that and shouldn't allow it, so those reports are counted as noise.
Can I hash the inline script from the report's sample?
No. Browsers include only the first 40 characters as a sample, and a hash has to cover the whole script exactly. Hash the full block from your source, or give it a nonce.
What's the difference between report-uri and the Reporting API?
report-uri is the older directive; browsers POST one {"csp-report": ...} object per violation. The newer report-to directive sends batches through the Reporting API, with camelCase fields. Many sites send both; this tool reads either.
Should I add 'unsafe-eval' or 'unsafe-inline' to stop the reports?
Avoid it. Both let injected code run, which is most of what CSP protects against. Find the library that uses eval, or move inline code into files or give it a nonce.
Is anything uploaded?
No. Reports can include page URLs and user paths, so everything is analysed in your browser.
