A Built-in CSP Report Endpoint for Every Monitor

If you have a Content-Security-Policy in production, you have a telemetry problem. Browsers silently block scripts, images, and styles that violate your policy — but unless you wire up report-uri or Reporting-Endpoints, you never find out. And if you do wire it up, you need an endpoint that accepts the reports, dedupes the floods, and shows you the signal.

Running your own endpoint is doable but not free — you need request parsing, dedup, retention, abuse protection, and UI. Most teams outsource it to a specialist service.

As of v1.12 every SiteGuardian monitor can be its own CSP report endpoint — bundled with your existing plan, fully EU-hosted, wired into the same alert rules you already use.

What you get

A per-monitor HMAC-signed URL — https://reports.siteguardian.io/r/{monitor_id}/{token}. Paste it into your Content-Security-Policy: report-uri … header (or the modern Reporting-Endpoints / Report-To pair). We handle both.
Aggregation instead of firehose. A misconfigured CSP can flood us with millions of reports from a single browser tab. We group them by (directive, blocked_uri, source_file) and store buckets — 1 M raw reports become one row with a count, three samples, and a browser breakdown.
GDPR-by-design. Client IPs are hashed with a daily-rotating salt (never stored raw). Query strings and fragments are stripped from document_uri and source_file before storage. We keep UA family (chrome/firefox/safari), never the full UA string.
Noise filtering. Browser-extension violations (chrome-extension://, moz-extension://), antivirus injections, and data/blob URIs are counted and dropped. You see what matters, not what a user installed on their machine.
Alert rules you already understand. Add csp_new_violation_type_count or csp_report_volume to an alert rule and get paged when a new violation type appears (classic CSP-drift detection) or when volume spikes (new deploy gone wrong).
Policy recommendations. After a week of reports we suggest allowlist additions — ranked by how many users each suggestion would unbreak.

How to enable it

On any monitor's detail page there's now a CSP Reports tab. One click provisions the endpoint; we generate a salt, sign the URL, and hand you a copy-paste snippet:

Content-Security-Policy: default-src 'self';
  report-uri https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d;
  report-to sg-csp
Reporting-Endpoints: sg-csp="https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d"
Report-To: {"group":"sg-csp","max_age":10886400,"endpoints":[{"url":"https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d"}]}

Deploy that header. Within seconds of real browser traffic, the tab lights up with your first bucket. Sort by count, click to drill into samples, and start tightening your policy.

Rate limits and safety

A single misconfigured CSP on a popular page can send us 10 k reports/s from one browser. nginx rate-limits at the edge (200 r/s per source IP with 400-burst), and per-monitor quotas auto-pause ingest for an hour if a monitor breaches three consecutive minutes of over-quota traffic. You'll never get billed for a crawl loop on your own site.

What about enterprise customers?

The same pipeline scales. The Business plan includes 1 M reports/month; beyond that, overages are €0.00005/report (5 orders of magnitude cheaper than what we'd charge if we weren't already running the infrastructure for uptime monitoring). White-label custom subdomains (reports.your-domain.com) are on the roadmap.

Why bother?

Because CSP without reporting is CSP on faith. You don't know which of your customers' sessions break every time the marketing team rolls out a new tag manager. You don't know that a vendor's CDN just added a new tracker that your policy doesn't allow. And you definitely don't know when a compromise is trying to load attacker-controlled script.

Now you do. And it's on by default in the plan you already have.

— Günter Weber, SiteGuardian