Open MazOneTwoOne opened 11 months ago
Assigning to @getsentry/support for routing ⏲️
Routing to @getsentry/product-owners-settings-projects for triage ⏲️
Routing to @getsentry/product-owners-issues for triage ⏲️
@armenzg can you take a look at this later?
@MazOneTwoOne Is that a tag? Can you use {{ tags.csp.script_sample }}
? (as mentioned in here).
Hello @armenzg sorry for the late response.
This is not part of the main Tags (the red box in the picture), but part of our CSP Report tags (the green box in the picture). We want to sub group by the script_sample
tags in our CSP Report.
Hope this make more sense.
@MazOneTwoOne thanks for the clarification! Since the value is not a tag, it looks like we don't support this as of yet. I'll mark this as a feature request and add it to our backlog.
For future reference, the code that handles the supported fingerprint variables is located here.
I'd like to +1 the need for Sentry to utilize the script_sample to distinguish CSP reports, so we can avoid ending up with catch-all titles like Blocked 'script' from 'eval:'
, Blocked 'style' from 'inline:'
and Blocked style attribute from 'inline:'
.
The problem I'm seeing is that user browsers have variety of extensions, some of which have poor compliance with strict CSP policies. It's so bad that almost 25% of our monthly quota of late is attributable to these issues, and the real problem is that we fail to identify if some code in our application is running afoul of the same policy and getting blocked as a result.
Utilizing the script sample is really the only mechanism to distinguish the various sources of inline CSP violations, and from what I've seen, it can be a highly reliable signature, as the offending code doesn't typically change from event to event.
The tricky part here is that it’s not the SDK which sends CSP reports, it’s the browser itself. That means that the workaround I’d normally suggest (for @MazOneTwoOne to do exactly what you doing, but with the SDK instead of with fingerprint rules) won’t work, because the SDK has no way to edit the outgoing payload.
So the solution really does have to be for us to support csp fields (or at least csp.script_sample
) as one of the variables you can use in fingerprint rules. So @robbytx, thanks for bringing this up again. We'll discuss internally how/when we want to proceed.
+1 Trying to suppress certain CSP violations while still seeing new CSP violations of a certain volume show up in sentry
Problem Statement
Issue Grouping - Fingerprint Rules
We are exploring the use of custom issue fingerprinting, for CSP notifications, so we can continue being alerted by them in Slack but also use the ‘archive’ function in Sentry. This is what we have for our UAT environment.
However it looks like the custom issue fingerprint is treating
csp.script_sample
as a literal value, rather than substituting in the value of the script sample, in our CSP report.Solution Brainstorm
No response
Product Area
Settings - Projects