W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2012

[webappsec] adding data to CSP reports with DOM API

From: Hill, Brad <bhill@paypal-inc.com>
Date: Tue, 31 Jul 2012 21:44:25 +0000
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1B7AB2@DEN-EXDDA-S12.corp.ebay.com>
[hat=participant]

As we start to further explore in CSP the idea of using the reporting mechanism to push security "up the stack" into behavioral and fraud analytics based on reporting, rather than blocking, things outside policy, it has occurred to me that we may want to enrich our reports.

For example, when processing reports based on the new UI safety directives, it may be quite useful to know things about the client capabilities and state that are not part of the standard report: Is this a touch UI?  What is the size of the viewport?  How long was the user on the page?

I'm interested to hear the group's thoughts on allowing scripts to add information to the report.

It seems at first thought that:


1)      The mechanism should be append-only

2)      Changing the URI of the report should probably be forbidden

Are there dangers in adding such functionality to CSP?  Is it better to just use XHR or similar to send a separate report that would need to be correlated on the back-end?  I lean towards using the same reporting mechanism specifically in the UI safety case because one hopes the events would fire rarely, but with some number of false positives.  Should we just add an onViolation callback handler to accommodate such cases, allowing avoidance of unnecessary extra data reporting?

-Brad
Received on Tuesday, 31 July 2012 21:44:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 31 July 2012 21:44:59 GMT