W3C home > Mailing lists > Public > public-web-security@w3.org > December 2011

CSP Errors and Report Data

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Fri, 9 Dec 2011 21:45:41 -0800
Message-ID: <CAPfop_3b396zr=E2qOF8esWC8VgBR1ZMPc2_d26LLj71dkC-CA@mail.gmail.com>
To: public-web-security@w3.org
This is great feedback.

One (stupid) question I had was whether you are talking about reports
generated by actual CSP deployment or the web application developers'
browser/console/f12-tools thing? If it's the later, then I feel that
the correct solution is for the browser vendors to give more detailed
data in the console instead of changing the spec for report data.


> For instance, what was the URL that triggered the mixed content warning.
> What we get now is "violated directive default-src 'unsafe-inline'
> 'unsafe-eval'".
>

This is also a good example of the use of CSP. Right now, if I am not
wrong, some browsers would just block the mixed content with no
knowledge to you.

> tagName=iframe&url=http://www.youtube.com/html5/xx11111
>

Would the tag name be enough? Wouldn't the class and id of the element
also be useful? Especially, if this is a bug that didn't manifest
itself in developer testing, then the tagname might be insufficient.

> And while that would be enough for the Mixed Content use case, for other use
> cases we've tried to use it (Like GMail+XSS for example), we might even need
> a stack trace.
>
> I remember someone (probably Adam?) was proposing triggering a DOM event (on
> top of the report-uri). If that contains more information it would be enough
> at least for us.
>

This seems like the best solution.

-devdatta
Received on Saturday, 10 December 2011 05:46:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 December 2011 05:46:31 GMT