Automating CSP Violation Detection: Your Options

If you’re managing a Content Security Policy (CSP) on your site, you’ve probably discovered that new plugins, themes, or third-party embeds regularly introduce resources your policy doesn’t yet allow — leading to blocked scripts, styles, images, or iframes. Rather than waiting for each violation to surface one at a time in a visitor’s browser console, CSP Violation Detection can be proactively detected in three ways.

1. Browser-Based Crawler (One-Off Audits)

A headless browser tool like Puppeteer or Playwright can visit every page on your site automatically, listen for CSP violation events, and generate a report of everything that got blocked — all in a single run.

How it works:

• The script crawls your sitemap (or follows internal links from the homepage)
• On each page, it listens for the browser’s native securitypolicyviolation event
• It collects the violated directive, blocked resource URL, and source location for every hit
• Results are deduplicated and exported as a CSV or JSON report

Best for: a quick, thorough audit before or after a site change — especially useful right after a plugin update or theme change, when new CSP violations are most likely to appear.

2. Native CSP Reporting (Ongoing Monitoring)

CSP has a built-in reporting mechanism: add a report-to directive (backed by a Reporting-Endpoints header) to your policy, and browsers will automatically send a JSON report to an endpoint you specify every time a real visitor triggers a violation — not just during a test crawl.

This catches issues a crawler might miss entirely: different browsers, logged-in vs. logged-out states, geo-blocked third-party resources, or scripts that only misbehave intermittently.

You have two choices for where reports go:

• Hosted reporting service — services like report-uri.com collect, dedupe, and dashboard your violations with essentially zero setup on your end. Good if you want monitoring running today.
• Self-hosted endpoint — a small script on your own server that receives and logs reports. More setup, but full control over the data and no third-party dependency.

Best for: continuous, real-world monitoring that reflects your actual visitor traffic, not just a simulated crawl.

3. Manual Console Checks (No Setup)

For a small site, simply opening Chrome DevTools → Console and clicking through the important pages by hand will surface most violations. Slower and easy to miss edge cases, but it requires no code or infrastructure at all.

Best for: spot-checking after a specific known change, on a small site with few pages.

Enforcing vs. Report-Only Mode

Whichever monitoring method you use, it’s worth knowing CSP supports two modes:

• Enforcing (the standard Content-Security-Policy header) — violations are blocked and reported.
• Report-Only (the Content-Security-Policy-Report-Only header) — nothing is blocked; violations are only logged. This is the safer way to test a policy change before rolling it out, since you can watch what would have broken without actually breaking it for visitors.

Which Should You Use?

For most sites, the strongest setup combines two of the above: a crawler for periodic, thorough audits (especially after updates), plus native CSP reporting running continuously in the background to catch anything real visitors encounter that a crawl alone wouldn’t surface.