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:
-
Sentry could have a tag which states which CSP header generated the violation. Current tags are as follows: blocker-uri, browser, effective-directive, …
-
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?