User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150223135440 Steps to reproduce: As per CSP >= 1.1 SPEC To send violation reports in CSP, the user agent MUST use an algorithm equivalent to the following: 1. Prepare a JSON object report object with a single key, csp-report, whose value is the result of generating a violation report object. 2. Let report body be the JSON stringification of report object. 3. For each report URL in the set of report URLs: 1. If the user agent has already sent a violation report for the protected resource to report URL, and that report contained an entity body that exactly matches report body, the user agent MAY abort these steps and continue to the next report URL. 2. Queue a task to fetch report URL from the origin of the protected resource, with the synchronous flag not set, using HTTP method POST, with a Content-Type header field of application/csp-report, and an entity body consisting of report body. If the origin of report URL is not the same as the origin of the protected resource, the block cookies flag MUST also be set. The user agent MUST NOT follow redirects when fetching this resource. Actual results: Though the origin of the report uri same as the origin of the protected resources COOKIES ARE NOT SET. This functionality suffers one major weakness, which is there is no guarantee of authenticity of the reports. An attacker can very easily send an administrator clicking an entire trail of malicious links in attempt compromise an admin system. Here are a few possible attack scenarios: Attacker crafts fake violation reports with malicious links. The links are loaded with BeEF modules to attack and possibly compromise the machine used to view logs. Attacker fuzzes payloads within the violation report to attack the backend application used to handle reports. Attacker floods the reporting URI with invalid data in a Denial of Service attack. Attacker creates several fake violation reports with innocuous but unique links which he or she owns. The attacker monitors web logs and waits for security teams to review violation reports. The attacker may learn of new networks by which the security team used to connect. Expected results: If the origin of the report uri same as the origin of the protected resources COOKIES MUST BE SET. This functionality is also working in google chrome

Kamil, Matt, if that is still an issue we should get it fixed. Can someone verify?

This is still an issue. Both Release Fx45 and Nightly Fx48 do not send cookies to the (same-origin) report-uri. However, Chrome does pass on the cookie. I tested using a cookie set via HTTP response header, and sent to a same-origin report-uri.

This is still not fixed. Without sending cookies with the report the request cannot reach backends that only allow requests from authenticated users (i.e. having a security session cookie, as it is usually the case in business environments). And using a public collector is not an option for such environments.