fix(core): Apply dataCollection.urlQueryParams to url.full and url.query - #23061
fix(core): Apply dataCollection.urlQueryParams to url.full and url.query#23061chargome wants to merge 3 commits into
dataCollection.urlQueryParams to url.full and url.query#23061Conversation
|
bugborzer run |
size-limit report 📦
|
|
bugbot 📿 |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit b82b19e. Configure here.
…rl.query` `urlQueryParams` only applied to `request.query_string` and `requestDataIntegration`. Everywhere else, query strings went to Sentry unfiltered. Spans are filtered in one central place (`captureSpan`) instead of at the ~57 write sites, which span ~18 packages and mostly have no access to the client. The pass runs after the `processSpan` hooks so integration-set attributes are covered, and before `beforeSendSpan` since explicitly user-attached data is not gated by `dataCollection`. Breadcrumbs do not go through the span pipeline, so those are filtered separately at write time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Breadcrumb query filtering had no test coverage, so re-leaking a token would not have failed CI. Adds cases for the default denylist, off mode, allowList and extra deny terms on both outgoing request breadcrumb paths. The node fetch path needs its own file because the existing test module mocks `getClient` without `getDataCollectionOptions`. Also fixes two span tests that claimed more than they asserted: one checks the span name is untouched but never looked at it, and the other claimed to cover attributes set after the span starts while passing them in at creation. The latter now registers a `processSpan` subscriber, mirroring how `requestDataIntegration` sets `url.full`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
b82b19e to
0e39522
Compare
nicohrubec
left a comment
There was a problem hiding this comment.
lgtm, costs some bundle size but I think it's worth it given the blast radius
|
@nicohrubec yeah this was the tradeoff to adding it centrally to |
| // Runs after the hooks above so that URL attributes set by integrations are filtered too | ||
| filterUrlSpanAttributes(spanJSON, client.getDataCollectionOptions().urlQueryParams); |
There was a problem hiding this comment.
m/q: Is it fine to apply this here where we can no longer distinguish between user-set vs. SDK-set values? My understanding was dataCollection is only scoped to SDK-set values? If I'm wrong, feel free to ignore this. Otherwise, we probably need to move filtering to the sites where we set the url attributes.
There was a problem hiding this comment.
That is the tradeoff: we have about ~50 callsites that would need to be guarded, new integrations would easily miss this filtering step that's why I put it here
There was a problem hiding this comment.
I'll try going down the helper function route we discussed offline
| export function filterUrlSpanAttributes(spanJSON: StreamedSpanJSON, behavior: CollectBehavior): void { | ||
| const attributes = spanJSON.attributes; | ||
| if (!attributes) { | ||
| return; | ||
| } | ||
|
|
||
| mapStringAttribute(attributes, URL_FULL, value => filterUrlQuery(value, behavior)); | ||
| mapStringAttribute(attributes, URL_QUERY, value => filterQueryParams(value, behavior)); | ||
| } |
There was a problem hiding this comment.
Static-lifecycle spans bypass the new url.full/url.query query-param filtering
This filter only runs inside captureSpan, so spans serialized through the static trace lifecycle — transaction-embedded spans in _convertSpanToTransaction (tracing/sentrySpan.ts) and static standalone spans via captureStandaloneSpanWithStaticCallback (tracing/spans/captureSpan.ts:184) — still send url.full/url.query query strings such as ?token=… to Sentry unfiltered.
Evidence
filterUrlSpanAttributeshas exactly one call site:captureSpan.ts:80insidecaptureSpan, which only serves the streaming span pipeline.captureStandaloneSpanWithStaticCallback(captureSpan.ts:184-207) serializes viaspanToJSONand returns without calling the filter; it is reached fromsendStandaloneSpanwhentraceLifecycle === 'static'with a staticbeforeSendSpan(sentrySpan.ts:567)._convertSpanToTransaction(sentrySpan.ts:461-471) embeds child spans into transaction events viaspanToJSON(descendant)with no filtering — the standard span path whentraceLifecycle: 'static'is configured.- Integrations set these attributes regardless of lifecycle:
browser/src/tracing/request.ts:398andcore/src/fetch.ts:403setURL_FULL/URL_QUERYfrom request URLs, so even the default sensitive-key denylist inshouldFilterDataKeynever runs for these spans. client.ts:242normalizestraceLifecycleto'stream'unless explicitly'static', so the gap only affects the opt-in deprecated static lifecycle — hence low severity.
Identified by Warden · security-review · DUQ-S9Q
urlQueryParamsonly applied torequest.query_stringandrequestDataIntegration. Everywhere else, query strings went to Sentry unfiltered — a?token=…was sent as-is.We filter spans in one central place (
captureSpan) instead of at the ~57 write sites, which span ~18 packages and mostly have no access to the client. One place also means a new integration cannot leak by forgetting to filter.Breadcrumbs do not go through the span pipeline, so those are filtered separately.
closes #23049