User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36 Steps to reproduce: 1. Set a Content Security policy of `default https://www.example.com; report-uri https://www.example.com/csp-report` for an HTML document. 2. Have the HTML document attempt to load an image with src of "http://www.anotherdomain.com/test.jpg". Actual results: A report is issued with a JSON payload that does not include the "effective-directive" and "status-code" properties. Expected results: A report should be issued with: "effective-directive": "img-src", "status-code": 200 From the CSP2 spec regarding "effective-directive": "The name of the policy directive that was violated. This will contain the directive whose enforcement triggered the violation (e.g. "script-src") even if that directive does not explicitly appear in the policy, but is implicitly activated via the default-src directive." And "status-code": "The status-code of the HTTP response that contained the protected resource, if the protected resource was obtained over HTTP. Otherwise, the number 0."
Thanks tollmanz - moving to DOM::Security.
Component: Untriaged → DOM: Security
Product: Firefox → Core
I have confirmed this behaviour in 40.0.3 and the values are missing from the reports. Appropriate parts of the spec: https://w3c.github.io/webappsec/specs/content-security-policy/#violation-report-effective-directive https://w3c.github.io/webappsec/specs/content-security-policy/#violation-report-status-code Examples of a report from Chrome (Version 47.0.2508.0 dev-m 64-bit) and Firefox 40.0.3 attached.
Issue confirmed as still present in 43.0.1 This makes it incredibly difficult to normalise CSP reports on collection as there is no effective-directive value to categorise incoming reports.
Adding in my "+1" here since this definitely makes it hard to do any sensible aggregation of CSP reports. Right now, we choose to completely disregard any reports that don't include an `effective-directive` value, which means, we get nothing from Firefox at the moment. But this is an acceptable tradeoff at the moment in my opinion, until Firefox is sending the expected data.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I know we are not setting the 'effective-directive' and also don't report the status-code. So that needs to be fixed and incorporated in the JSON report, somewhere around here: http://mxr.mozilla.org/mozilla-central/source/dom/security/nsCSPContext.cpp#756
Note that several CSP reporting tools (Sentry being one of them) are actively rejecting all Firefox CSP reports currently due to lack of these fields.
(In reply to Reed Loden [:reed] (use needinfo?) from comment #7) > Note that several CSP reporting tools (Sentry being one of them) are > actively rejecting all Firefox CSP reports currently due to lack of these > fields. This is something I considered for https://report-uri.io but in the end I decided to add specific handling for Firefox. I parse the effective-directive out of violated-directive but this does introduce additional problems. When the block was a fallback to default-src I end up with an effective-directive of default-src, which makes filtering in the GUI a pain. I could try and be smarter and detect the actual effective-directive, but decided how I currently do it is a good balance between dropping all Firefox reports and manually trying to identify the actual effective-directive.
Priority: P1 → P3
Whiteboard: [domsecurity-backlog] → [domsecurity-backlog1]
I doubt bug 1363326 is a duplicate: https://w3c.github.io/webappsec-csp/#report-violation. It seems CSP3 suggests different reporting for `report-to` and `report-uri`
Yeah, there's quite a shift in reporting for CSP3 but I think this bug is still relevant for the report payload.
This first patch makes CSP to report the effective directive, following what the spec says.
Assignee: nobody → amarchesini
Status: NEW → ASSIGNED
Probably this is not the right approach. We should implement the algorithms https://w3c.github.io/webappsec-csp/#should-directive-execute https://w3c.github.io/webappsec-csp/#directive-fallback-list https://w3c.github.io/webappsec-csp/#effective-directive-for-inline-check but this is a big refactoring of the current CSP implementation.
Comment on attachment 9004472 [details] [diff] [review] part 1 - report correct directive name I'm not happy about these 2 patches. removing the review flag.
You need to log in before you can comment on or make changes to this bug.