Skip to content
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

Open
jonathanKingston opened this issue Feb 25, 2021 · 3 comments
Open

Add report samples to security considerations #470

jonathanKingston opened this issue Feb 25, 2021 · 3 comments

Comments

@jonathanKingston
Copy link
Contributor

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

@arturjanc
Copy link

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?

@jyasskin
Copy link
Member

jyasskin commented Mar 1, 2021

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.

@ScottHelme
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants