0

I'm looking into the W3C Reporting API, which enables websites to instruct the client (browser) to send reports about: browser crashes, network errors, browser interventions etc. ouside the JS enviroment.

My current understanding says it works by having the server respond with a Report-To HTTP header, which the browser can use to send POST requests containing one or more reports in a standardized JSON format.

However, what prevents a malicious user from looking at the HTTP response headers with the intention of copying the Report-To endpoint and send forged requests with bogus reports?

To me it seems there is nothing in the spec that helps agains this, right? I can't help, but wonder how this hasn't been mentioned as the impact of ths would decrease the value of the reports to a point where the developers of the site cannot rely on them. You know, garbage in = garbage ou.

I have spent some time researching various solutions on how to mitigate spam on public api endpoints and have reached a possible solution, but it's not without its flaws. Here goes: The server provides each client with a nonce or otherwise unique endpoint so that it can distinquish them. Then implementing a throttling mechanism to detect large amounts of requests from the same client. Something which I believe would be unlikely.

However, throttling doesn't stop an attacker from sending few requests with a randomized interval to avoid patterns and with possibly randomized types of reports. And remember the spec allows a single request to contain multiple reports, so this could lead to large amounts of false-positives.

You could make the nonce have a short lifetime and get a new one with the next request, but this creates the risk of ignoring valid reports if the nonce expires beforehand. This is also an issue in single page/progressive web apps where the request which contains the Report-To header in the response (the index page etc.) is repeated with large intervals (on updates in the case of PWA's).

The question

How would you go about mitigating or at least detecting forged/spam requests in a public and thus anonymous API endpoint?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.