Open MazOneTwoOne opened 1 year 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
Is there an update on this? Is there any way to access the CSP issue's variables?
We've got a Blocked 'script' from 'inline:'
catch-all that we'd like to discern so we have visibility for similar CSP errors in the future.
Only unique fields we have are the column_number
and line_number
, though. Does anyone know why the script_sample
is empty (both for enforce and report only)? I couldn't find anything about the field in the docs or the source code.
Does anyone know why the script_sample is empty (both for enforce and report only)?
@druvisc you may need to add the report-sample
keyword to the script-src
/style-src
directives in your CSP, to instruct the browser to include a sample in its CSP violation report.
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