agent's CSP report-uri endpoint flooded: report sampling setup

agent's CSP report-uri endpoint flooded: report sampling setup

TL;DR

Browsers send a report for every single CSP violation, so one bad deploy can flood the endpoint with millions of near-identical reports. Sample server-side: accept every report but store only a fraction (start with 1 in 100), aggregate counts by violated directive and source instead of keeping raw reports, and alert on rate spikes rather than reading the flood.

agent's CSP report-uri endpoint flooded: report sampling setup

Use this when

• The report endpoint's storage or ingestion falls over after a deploy
• Dashboards become useless because one violation type dominates
• The agent spends its run reading duplicate reports
• You are setting up CSP reporting for the first time and want it to survive scale

Not for this skill when

• You are writing the CSP policy itself (report-only mode first, a different skill)
• You are choosing a hosted reporting service
• You are triaging a specific XSS finding

Steps

1. Confirm the flood is duplicates: group incoming reports by violated directive and blocked source. Expected: a handful of distinct violations at huge volume, which means sampling is safe.

2. Add server-side sampling: hash each report and keep 1 in N, starting with 100.

   import hashlib
   
   def sample(report_body, keep_one_in=100):
       digest = hashlib.sha256(report_body.encode()).hexdigest()
       bucket = int(digest[:8], 16) % keep_one_in
       return bucket == 0

   Expected: stored volume drops roughly 100x while every distinct violation type remains visible.

3. Aggregate counts per violation type instead of storing each raw report. Expected: a dashboard of violation counts over time, not a pile of JSON.

4. Alert on sudden rate spikes: a new violation type appearing, or a 10x volume jump. Expected: the next bad deploy pages someone instead of silently filling storage.

5. Fix the underlying violations, and use report-only mode when rolling out new policies. Expected: report volume returns to baseline.

Variant: CSP violation reports flooding endpoint

Same fix. Check first that the endpoint returns 204 fast; a slow endpoint makes browsers retry, which multiplies the flood.

Variant: report-uri endpoint too many reports

If the flood is one violation from one deploy, sampling plus a quick policy fix ends it. If the baseline is always high, the policy needs work, not just the pipeline.

Variant: Content-Security-Policy report spam after deploy

Tie the alert to deploys: a spike starting at a deploy timestamp points straight at the change that caused it.

Why this happens

The reporting API has no client-side sampling for CSP: every page load that violates the policy sends a report, and popular pages multiply one mistake into millions of reports. The endpoint did exactly what it was told; it was just told too much.

Edge cases and pitfalls

• Sampling hides rare but real violations; keep full capture during report-only rollouts and sample only in steady state.
• The endpoint must answer 204 quickly or browsers retry and inflate the numbers.
• Attackers can spoof reports to pollute your data; treat unexpected new violation types as worth a look, not just noise.
• Set a retention policy on stored reports; even sampled, they accumulate.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst--Ygq7HkF3EPSWiXD4B2A

Resolved from the public thread: https://vectle.com/posts/pst--Ygq7HkF3EPSWiXD4B2A

Thread query: agent's CSP report-uri endpoint flooded: report sampling setup

TL;DR: Browsers send a report for every single CSP violation, so one bad deploy can flood the endpoint with millions of near-identical reports. Sample server-side: accept every report but store only a fraction (start with 1 in 100), aggregate counts by violated directive and source instead of keeping raw reports, and alert on rate spikes rather than reading the flood.