fix(core): Apply dataCollection.urlQueryParams to url.full and url.query - #23061
Open
chargome wants to merge 6 commits into
Open
fix(core): Apply dataCollection.urlQueryParams to url.full and url.query#23061chargome wants to merge 6 commits into
dataCollection.urlQueryParams to url.full and url.query#23061chargome wants to merge 6 commits into
Conversation
Member
Author
|
bugborzer run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
size-limit report 📦
|
Member
Author
|
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>
chargome
force-pushed
the
fix/gate-url-query-params-on-data-collection
branch
from
August 5, 2026 14:42
b82b19e to
0e39522
Compare
chargome
marked this pull request as ready for review
August 5, 2026 15:02
chargome
requested review from
andreiborza,
msonnb,
nicohrubec and
stephanie-anderson
and removed request for
a team and
stephanie-anderson
August 5, 2026 15:02
nicohrubec
approved these changes
Aug 6, 2026
nicohrubec
left a comment
nicohrubec
left a comment
Member
There was a problem hiding this comment.
lgtm, costs some bundle size but I think it's worth it given the blast radius
Member
Author
|
@nicohrubec yeah this was the tradeoff to adding it centrally to |
Lms24
reviewed
Aug 6, 2026
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
chargome
marked this pull request as draft
August 6, 2026 11:00
Replace the central `captureSpan` filtering pass with a `filterCollectedUrl` helper that every instrumentation site calls when it records a URL. The central pass could not tell an SDK-set attribute from one a user set themselves, so a `url.full` passed to `span.setAttribute()` was filtered too. `dataCollection` is only meant to gate automatically collected data. Routing the SDK's own URLs through a helper makes provenance structural: a URL the user attaches never passes through it, so it is left alone. The helper reads `urlQueryParams` from the client itself, so call sites only wrap the value and `getHttpSpanDetailsFromUrlObject` keeps its signature. Attributes copied in from third-party OTel instrumentation are filtered where the SDK copies them, in `inferSpanData`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`http.target` is the deprecated alias of `url.full` and carries the same path and query string, so it bypassed `dataCollection.urlQueryParams` and sent sensitive query params even though `url.full` was filtered. Three sites were affected: both incoming server span integrations build it as `pathname + search`, and the outgoing client span uses `request.path`, which Node populates with the query string included. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Member
Author
|
@Lms24 @nicohrubec I updated the pr to gate at the internal call sites so now it's actually spec compliant. For regression safety we can add a custom lint rule maybe, need to look into it. |
chargome
marked this pull request as ready for review
August 6, 2026 13:30
chargome
requested review from
Lms24,
mydea,
nicohrubec and
s1gr1d
and removed request for
a team,
mydea and
s1gr1d
August 6, 2026 13:30
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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