Introduce rate limiting for violation reports (report-uri and report-to)

[danmx]

CSP should be able to rate limit violation reports send to report-uri or report-to, e.g. by setting a percentage 0-100. This would make it easier for high traffic sites to start adopting CSP and would reduce possibility of DDoSing reports' receiver in case of violation.

My proposal:
Before sending a violation browser will draw a random number from 1 to 100 if the number is lower or equal than rate limit setting (0-100) it'll send a violation.

[michaelficarra]

You can configure your server to only include the report-uri directive in a portion of responses.

[jacobbednarz]

@michaelficarra That's a great start and will work for some however I don't think it's possible for all scenarios. For example, sites that use caching + a front end technology to populate the dynamic data won't be able to benefit from that approach. There are also benefits to having this within the spec and browser vendors managing it better since violation denial of service is a very real threat and I think anything we can do at the browser level to help this will be better for all.

@danmx I'm unsure on the randomness nature of that proposal. I'd rather a reproducible alternative that was consistent. There was talk (I cannot remember from who or where so take this with a grain of salt) around batching reports and just sending them at once after some deduping magic that would reduce the number of reports that an origin seen as well as an upper limit on reports that were sent.

[devd]

Can't you also catch the CSP exceptions in JS and then do whatever you want (rate limit, rate limit by type of report, etc etc)? Application code can be a lot smarter than browser code.

[danmx]

@michaelficarra that will not work with caching responses (browser cache or CDN)

@jacobbednarz batch and deduplication will work for single UA (will prevent sending same reports every page view) but you still will have huge spikes and duplicated reports when you have a lot of unique page views (millions of users viewing your site). Randomness works in other protocols like e.g. DMARC

@devd but you'll have to be sure that your JS will load 1st so you still may lose some violations or your JS can be blocked by misconfigured CSP (misconfigurations are often)

[mikewest]

If we do something like this, I'd like for it to be the Reporting API's responsibility. I think any changes to report-uri are unlikely to be interoperably implemented at this point, and https://github.com/WICG/reporting/issues/45 seems like a better approach to configuring reporting going forward. Let's continue the conversation there.

(/cc @andypaicu)

[odinho]

Dead link --^. Here's the new one: w3c/reporting#45

Not coming anytime soon it looks like for 2022. :)