Tracing headers are attached to protocol-relative URLs by default, causing CORS errors

[gongpeione]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/browser

SDK Version

7.48.0

Framework Version

No response

Link to Sentry event

No response

SDK Setup

const options = {
    ...
    tracesSampleRate: 1,
    integrations: [
        new Sentry.BrowserTracing()
    ]
}

Steps to Reproduce

1. import and setup Sentry
2. add a request like fetch('//xxx.xxx.com/xxx')
3. run the code
4. custom headers added to requests and causes CORS error

Expected Result

Based on my understanding of the line const DEFAULT_TRACE_PROPAGATION_TARGETS = ['localhost', /^\//]; Link, I would expect custom headers to only be added to non-cross-origin requests by default. This would be the case if the requests are targeting 'localhost' or if the request URL starts with a '/'.

However, I've noticed that this logic might not account for protocol-relative URLs (those starting with //, like //example.com). If my understanding is correct, this could potentially result in custom headers being added to these types of requests, which might not be the intended behavior

Actual Result

custom headers added to requests and cause CORS error.

If possible, I can submit a pull request to address this issue.

[Lms24]

Hi @gongpeione thanks for writing in!

Based on my understanding of the line const DEFAULT_TRACE_PROPAGATION_TARGETS = ['localhost', /^//]; Link, I would expect custom headers to only be added to non-cross-origin requests by default

Yes, that's exactly how the default value should behave.

However, I've noticed that this logic might not account for protocol-relative URLs (those starting with //, like //example.com).

Hmm you're right, this would match with the /^\// default regex. But to be honest, I didn't know that this is a valid and usable URL. Can you show us a concrete reproduction? Would fetch('//example.com') be one of them?

[gongpeione]

Hi @gongpeione thanks for writing in!

Based on my understanding of the line const DEFAULT_TRACE_PROPAGATION_TARGETS = ['localhost', /^//]; Link, I would expect custom headers to only be added to non-cross-origin requests by default

Yes, that's exactly how the default value should behave.

However, I've noticed that this logic might not account for protocol-relative URLs (those starting with //, like //example.com).

Hmm you're right, this would match with the /^\// default regex. But to be honest, I didn't know that this is a valid and usable URL. Can you show us a concrete reproduction? Would fetch('//example.com') be one of them?

Yes, fetch('//example.com') could reproduce this situation.