Ideal usage of Content-Security-Policy (CSP)

Sentry supports CSP natively and this endpoint can receive CSP violations from both Content-Security-Policy and Content-Security-Policy-Read-Only. However, once a CSP violation is received by Sentry there’s no way to determine if the violation was generated by either the CSP or CSP-read-only header.

Possible solutions:

  1. Sentry could have a tag which states which CSP header generated the violation. Current tags are as follows: blocker-uri, browser, effective-directive, …

  2. Customers have to create two projects Foo & Bar where a developer specifies Foo CSP endpoint in CSP report-uri and specifies Bar CSP endpoint in CSP-read-only report-uri.

Should customers be encouraged to create two projects for CSP and CSP-read-only or should the Sentry CSP logger be enhanced to inform which header generated the violation?

Thoughts?

2 Likes