# 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.

```text
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.
   ```python
   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_--Ygq7HkF3E_PSWiXD4B2A