-
Notifications
You must be signed in to change notification settings - Fork 78
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
Add report samples to security considerations #470
Comments
This seems reasonable, but I think the risk extends to other data present in the violation report (e.g. the document's URI, the referrer, the blocked URI -- all of which could contain sensitive tokens or be capability URLs). We may want to add a general warning about the report potentially containing sensitive information, and advising developers to take care when configuring the report-uri to ensure it points to trusted infrastructure, if the spec doesn't cover this yet? |
I think it's also useful as advice to folks running reporting endpoints, that they need to treat the data they receive as possibly including user data, not just information about the source website. |
Full transparency; I'm the founder of https://report-uri.com so I have a commercial interest in CSP reporting. I think I'm more aligned with @arturjanc on this one in that realistically, any field in a report could contain user data so at Report URI we try not to focus on the content of any particular field, but rather a holistic view of the whole report. The simple act of sending a report will yield the source IP and User Agent string of the sending client which sits outside of the content of the report too. I recently wrote an article on Transparency about Data Protection at Report URI that outlines the work we do in this area and the various filters we have to help customers minimise the amount of potential user data we store or process. As you can see in our Data Protection and Records of Processing documents, we've done our best to provide as much information as possible for customers to consider their position on the impact of enabling reporting. We also have a DPA if our customers determine that we need to be designated as a Data Processor. I think I'd prefer to see the specification point out that privacy needs to be considered, rather than trying to make more specific points like 'field x could contain user data'. |
Despite their limited exposure report samples could contain user data and this could be sent through the reporting API to a third party.
It may be worth highlighting in the security considerations for people reading the specification.
/cc @jyasskin
The text was updated successfully, but these errors were encountered: