Mark impossible CSP reports as such

[patrakov]

Problem Statement

I receive a lot of CSP reports that look impossible. One example (slightly edited for privacy reasons, and yes, this report-only policy is indeed too-open):

{
  "csp-report": {
    "effective_directive": "script-src-elem",
    "blocked_uri": "https://www.google-analytics.com/analytics.js",
    "document_uri": "https://www.my-domain.com/about/career",
    "original_policy": "default-src 'self' https:; script-src 'self' https: 'unsafe-inline' 'unsafe-eval'; ...",
    "referrer": "https://www.google.com/",
    "status_code": 200,
    "violated_directive": "script-src-elem",
    "script_sample": "",
    "disposition": "report"
  }
}

As you can see, there is no reason for https://www.google-analytics.com/analytics.js to be blocked, because it is served via https and all https origins are allowed for scripts. Ideally, Sentry should be able to see this as well.

I want:

• To get some tag (e.g. "csp:impossible") visible in the issue overview for such reports;
• To make sure that possible reports are never grouped together with the impossible ones;
• To be able to completely ignore impossible reports on some projects.

Solution Brainstorm

Impossible CSP errors can appear due to a variety of reasons. E.g., the "Adblock" (non-plus) Chrome extension is a major source of them. See also https://csplite.com/csp277/

[markstory]

The doc you linked to calls out that the status_code: 0 is related to privacy extensions but your report has status_code:200 which indicates a request was made and then blocked.

Did this report happen to come from Safari? I've observed Safari giving false reports when report-only and an enforce policy are defined.

Re-evaluating CSP reports and the original_policy is an interesting idea. There isn't any current work planned for CSP so this will likely sit idle for a while.

[patrakov]

This particular CSP violation attracts a mix of Chrome on Mac OS X 10.15.7, Chrome on Windows 10, and Edge on Windows 10. No Safari seen so far.

I guess that status_code: 200 was because this policy is still in report-only mode, and therefore does not block anything.

[henricook]

Dealing with these "impossible CSP reports" where it says something was blocked but the status code is 200 is the bane of my existence, as the guy who watches Sentry the most in my org. I feel bad when I ignore them, but know they're not causing anyone a problem because no users are reporting issues.