Issues - Being able to adjust specific issue sample rate for Content Security Policy errors

[Angelodaniel]

Problem Statement

In this case the Content Security Policy errors eat up most quota but are still important to the developers In order to reduce the amount of traffic and save some quota I want to know if it's possible to use something similar like the tracesSampler for JS however it seems that there is no similar option for CSP (Sentry Docs).

Also the Sentry UI doesn't give options to do like a Dynamic Sample on all CSP issues so it's either filter them out completely or don't filter and accept all.

Solution Brainstorm

No response

Product Area

Issues

┆Issue is synchronized with this Jira Improvement by Unito

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-issues for triage ⏲️

[lobsterkatie]

The reason there's isn't a tracesSampler-type option for CSP reports is because they're not sent by the SDK, they're sent by the browser.

It seems like it might be possible to have the SDK listen for and catch them (and therefore possibly be able to sample them - would depend on whether the SDK can prevent them from being sent or only observe them on their way out the door), but only in cases where the SDK is already initialized when the violation occurs.

We could also set up sampling and/or rate limiting on our end, but I suspect that would have to be a larger conversation. I'm therefore going to transfer this to the JS repo, as I think it's your best bet as at least a place to start.

[lobsterkatie]

Also of possible interest that I just found: You're apparently not the only one with this request, though the conversation seems to have died out in 2019. Perhaps you could revive it!

[AbhiPrasad]

It seems like it might be possible to have the SDK listen for and catch them

I think this is entirely new behavior for CSP functionality as we would have to build a new integration to the SDK (and add new envelope logic) to make this work. IMO we should be working toward adding some controls in the UI to help with this.

I'm not even sure which team should own CSP stuff - I'll defer to @smeubank re: this.

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[ryanseddon]

Did anything come of this? I'm interested in sampling CSP too but unsure if that's feasible due to the browser controlling sending of reports.

[smeubank]

after chatting with @oioki this is something which happens outside of the JS SDK. If we want to to filter we need to investigate something with inbound filters potentially. I at least would vote to come up with a way to drop these on server side, project config. And not add this complexity to the SDK just to sample.

cc @rachrwang

[getsantry[bot]]

Routing to @getsentry/product-owners-issues for triage ⏲️

[malwilley]

Thanks for getting to the bottom of this! Will place on the backlog, but this isn't something that's on our roadmap currently.

[scottohara]

Understand and appreciate that this request has been moved to a backlog, and I'm very much looking forward to one day being able to reduce some of the noise from CSP reporting that is drowning out the "signal" from genuine application-level errors.

I do wonder if there's a potential "quick win" here, by tapping into the existing "Filter out errors known to be caused by browser extensions" feature?

Currently, I have this filter turned on (and I assume it's working, as I don't see too many application-level errors that could be attributed to browser extensions); however I do still quite regularly see CSP reports such as:

blocked_uri         wasm-eval
disposition         enforce
effective_directive script-src
source_file         chrome-extension
violated_directive  script-src

My view is that if someone has opted into filtering out errors caused by browser extensions, that should extend to CSP reports as well?

[jangjodi]

Hi @scottohara, thank you for the suggestion. This is a valid request, but given our current bandwidth it's not something we’ll likely get to soon.