Site Isolation wants to restrict / lock-down which origins a particular renderer can talk to.  This goal seems incompatible with the ability to send CSP violation reports to any cross-origin.

This problem is somewhat similar the problem of allowing any cross-origin fetches from Content Scripts - see  issue 726951 .


There are 2 CSP directives that might result in an HTTP POST with report violation data: 'report-uri' and 'report-to'.

'report-uri' is being deprecated and replaced with 'report-to' (which builds on top of the new reporting API spec/feature - http://wicg.github.io/reporting/).

Both 'report-uri' and the Reporting API seem to allow reporting to a cross-origin destination.  In particular, there are tests for 'report-uri' that (AFAICT) validate that a cross-site report was successful: third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/report-cross-origin-no-cookies.php

AFAIK, both 'report-uri' and 'report-to' can be declared inside a <meta> element (and so both are parsed inside a renderer and can be lied about by a compromised renderer).


I think that the test above specifically verifies that the CSP violation report is sent *without* cookies (I am guessing that this corresponds to WebURLRequest::kFetchCredentialsModeSameOrigin).  So maybe there is no problem.  OTOH, the Reporting API spec says in http://wicg.github.io/reporting/#send-reports to include credentials.


Reporting of CSP violations currently goes through PingLoader::SendViolationReport.  This class is responsible for other HTML requests, including processing of "ping" attribute of anchor (<a>) elements - interestingly the other kind of pings is restricted to same origin (i.e. I see a check for frame->GetDocument()->GetSecurityOrigin()->CanAccess(ping_origin.Get())).