New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce rate limiting for violation reports (report-uri and report-to) #227
Comments
You can configure your server to only include the report-uri directive in a portion of responses. |
@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. |
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. |
@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) |
If we do something like this, I'd like for it to be the Reporting API's responsibility. I think any changes to (/cc @andypaicu) |
Dead link --^. Here's the new one: w3c/reporting#45 Not coming anytime soon it looks like for 2022. :) |
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.
The text was updated successfully, but these errors were encountered: