The image upload request addresses the imagehoster as ${UPLOAD_HOST}/hs/${token} (packages/sdk/src/modules/private-api/requests.ts), so the user's access token travels in the URL path rather than in a header.
Sentry's breadcrumbs integration records fetch and XHR URLs verbatim, and apps/web/src/utils/sentry-before-send.ts only reads breadcrumbs, it never rewrites them. Any client error captured in a session where an upload happened can therefore carry that path in its breadcrumb trail. Nothing about the token itself is malformed, it is simply in the one part of the request that telemetry treats as safe to log.
Two pieces of work, the first cheap and the second the actual fix.
1. Scrub it in beforeSend (defensive, do this first)
Rewrite the path segment of any i.ecency.com/hs/* breadcrumb URL before the event leaves the browser. This is a few lines in sentry-before-send.ts and closes the exposure for every event from that point on, whatever else changes. Worth adding a spec so the redaction cannot silently regress.
While in there, consider a general rule rather than a single host match, since any future endpoint that puts a secret in a path inherits the same problem.
2. Accept the token in a header
The durable fix is for the upload endpoint to read the token from an Authorization header, with the path form kept only as long as older clients need it. That takes an imagehoster change plus the SDK call site, so it is the bigger half.
Related
Anything that serializes a raw error object's own properties would expose the same value a second way, through an Axios error's config.url. The Sentry client config currently installs default integrations only, so extraErrorDataIntegration is not active and this path is closed today. Worth a comment at the config so it does not get switched on without the scrubbing in place.
The image upload request addresses the imagehoster as
${UPLOAD_HOST}/hs/${token}(packages/sdk/src/modules/private-api/requests.ts), so the user's access token travels in the URL path rather than in a header.Sentry's breadcrumbs integration records fetch and XHR URLs verbatim, and
apps/web/src/utils/sentry-before-send.tsonly reads breadcrumbs, it never rewrites them. Any client error captured in a session where an upload happened can therefore carry that path in its breadcrumb trail. Nothing about the token itself is malformed, it is simply in the one part of the request that telemetry treats as safe to log.Two pieces of work, the first cheap and the second the actual fix.
1. Scrub it in
beforeSend(defensive, do this first)Rewrite the path segment of any
i.ecency.com/hs/*breadcrumb URL before the event leaves the browser. This is a few lines insentry-before-send.tsand closes the exposure for every event from that point on, whatever else changes. Worth adding a spec so the redaction cannot silently regress.While in there, consider a general rule rather than a single host match, since any future endpoint that puts a secret in a path inherits the same problem.
2. Accept the token in a header
The durable fix is for the upload endpoint to read the token from an
Authorizationheader, with the path form kept only as long as older clients need it. That takes an imagehoster change plus the SDK call site, so it is the bigger half.Related
Anything that serializes a raw error object's own properties would expose the same value a second way, through an Axios error's
config.url. The Sentry client config currently installs default integrations only, soextraErrorDataIntegrationis not active and this path is closed today. Worth a comment at the config so it does not get switched on without the scrubbing in place.