fix(core): Prevent functionToStringIntegration from throwing on cross-origin realms#22273
fix(core): Prevent functionToStringIntegration from throwing on cross-origin realms#22273mydea wants to merge 3 commits into
Conversation
size-limit report 📦
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 69701ca. Configure here.
| let context = thisArg; | ||
|
|
||
| try { | ||
| if (SETUP_CLIENTS.has(getClient()!) && originalFunction) { |
There was a problem hiding this comment.
Unguarded non-null assertion
Low Severity
New non-null assertion on getClient()! has no comment explaining why a safer type is impossible. Elsewhere in this package the usual pattern is to bind getClient() and null-check before use, which also avoids the assertion. Flagged because it was mentioned in the PR review guidelines rules file.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 69701ca. Configure here.
There was a problem hiding this comment.
this is fine, if we do has(undefined) it will simply return false
…-origin realms The patched `Function.prototype.toString` reads the Sentry carrier off `getClient()` on every invocation. When `this` (or the global object) is a `WindowProxy` whose browsing context was navigated cross-origin, that read throws a `SecurityError`. Since the patch lives on `Function.prototype`, any third-party `.toString()` call hits it, turning harmless introspection into uncatchable error noise. Wrap the patch body in a try/catch and fall back to the native `toString` so it never throws where the native impl would not. Fixes #21965 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
69701ca to
2f8b46e
Compare


The default
functionToStringIntegrationpatchesFunction.prototype.toString. The patched function reads the Sentry carrier offgetClient()(→getMainCarrier()→getSentryCarrier(GLOBAL_OBJ)→GLOBAL_OBJ.__SENTRY__) on every.toString()invocation.GLOBAL_OBJis aWindowProxyin browser realms. When its browsing context is later navigated cross-origin while code from the old realm can still be invoked (e.g. a parent window holding a reference into a same-origin child iframe whosesrcchanged to a cross-origin URL), the__SENTRY__read throws aSecurityError.Because the patch lives on
Function.prototype, the throw is triggered by any third-party.toString()call, converting harmless introspection into uncatchableSecurityErrornoise that Sentry then reports as unhandled-rejection events.Root cause
The native
Function.prototype.toStringnever throws for these calls — the throw is introduced solely by the integration's internal carrier access. The fix wraps the patch body in atry/catchand falls back tooriginalFunctionToString.apply(this, args), mirroring the defensive style already used around the patch installation. This keeps the unwrap behavior intact for live realms and degrades to exact native semantics when the carrier read throws.Fixes #21965
🤖 Generated with Claude Code