Enable call stack for blocked_uri in Content Security Policy Reporting
Reported by
vse...@oath.com,
Nov 16 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: With the current implementation of CSP reporting, the blocked_uri tells the URI of the resource that was blocked from loading on a given document on which the violation occurred. However, lot of times the blocked resource might not be loaded by the document and could be loaded by another resource which is hard to determine with the current implementation and hence it does not help with identifying the caller for the blocked_uri. It would be helpful if in addition to blocked_uri, an additional attribute could be provided that gives the stack of uris that led to the calling of the bolcked_uri on the document on which the violation occurred. What is the expected behavior? What went wrong? This is a CSP enhancement request. Did this work before? N/A Chrome version: 61.0.3163.100 Channel: n/a OS Version: OS X 10.12.6 Flash Version:
,
Nov 17 2017
+Andy: Could you triage this into the CSP backlog somewhere? I think we have a request for this from aaj@'s team already that I couldn't find quickly. If we implement it, we'll need to be careful not to expose any stack detail for cross-origin resources whose errors are muted[1], but it seems otherwise like a reasonable request. [1]: https://html.spec.whatwg.org/#muted-errors
,
Nov 17 2017
I think we discussed stack traces in the context of debugging eval() violations, but we settled on script-sample as the vehicle to provide the extra information in that case. I agree this seems like a useful feature; however, for nonce-based policies specifically it appears less applicable because additional scripts will be blessed by 'strict-dynamic' so it's consequently less likely that developers would see any violations.
,
Nov 20 2017
Seems interesting but it's not entirely clear to me how this stack trace would work as not everything that can load a resource has a URI. Inline scripts can load resources, event handlers can load resources and it's not really clear how we would represent it in this stack trace. Perhaps some examples would clarify how this would work.
,
Nov 20
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 6
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by wangyix@chromium.org
, Nov 16 2017