CORS header 'Access-Control-Allow-Origin' missing

It seems Tor Browser sometimes strips the Access-Control-Allow-Origin header. I ran into the issue when using Globe. When the header is stripped the browser console contains the warning

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://onionoo.torproject.org/details?lookup=299F0933E93B6571ED1CB3D52090E6E13D62427C. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

The reasons why i believe Tor Browser is the cause are

1. Onionoo explicitly sets the header.
2. Responses from direct requests to an Onionoo resource using Tor Browser sometimes do not show the header in the Network Monitor.
3. Responses from direct requests to the same Onionoo resource using curl consistently contain the header.

added TorBrowserTeam202006 component::applications/tor browser owner::tbb-team priority::medium severity::major status::new tbb-usability-website type::defect labels

Hrm. I tried a bit and looked at our code but did not see anything obvious. Steps for reproducing would be really helpful here.

Trac:
Status: new to needs_information

Replying to gk:

Hrm. I tried a bit and looked at our code but did not see anything obvious. Steps for reproducing would be really helpful here.

I cannot reproduce it reliably but it happens sometimes with the following steps.

1. Go to [https://onionoo.torproject.org/summary?limit=1].
2. Open Firefox Developer Tools.
3. Go to the Network tab.
4. Refresh the page with F5.
5. Look at the response headers of the first (and only) request.
6. If the Access-Control-Allow-Origin header is not missing, go to step 4.

After 3-5 refreshes the header disappears. However, it can also reappear and disappear again with subsequent refreshes.

FWIW I'm using Tor Browser 5.0.7.

Oops, algorithm in comment:2 is not so plain: first request is the second actually (first was in step 1), it always misses header on alpha, except exitnode was changed by timeout, how can it reappear if algorithm states to update only when header is not missing?

Replying to bugzilla:

Oops, algorithm in comment:2 is not so plain: first request is the second actually (first was in step 1) If the Firefox Developer Tools window isn't open at step 1, the Network tab doesn't show any requests when you first open it. With the first request i meant the first one in the request list in the Network tab after the refresh at step 4. There should be only one request in this list because the page i linked has no other resources it needs to load. Furthermore, the list of requests gets cleared after each refresh (which is the default unless the setting has been changed).

it always misses header on alpha Does loading node information on [https://globe.torproject.org/] work for you on alpha when the header is missing?

except exitnode was changed by timeout Did the exit node change alter the responses you got?

how can it reappear if algorithm states to update only when header is not missing? This could happen when you continue to refresh after you found that the header is missing. The steps are only to reproduce the missing header case.

Replying to cypherpunks:

Replying to bugzilla:

Oops, algorithm in comment:2 is not so plain: first request is the second actually (first was in step 1) If the Firefox Developer Tools window isn't open at step 1, the Network tab doesn't show any requests when you first open it. With the first request i meant the first one in the request list in the Network tab after the refresh at step 4. There should be only one request in this list because the page i linked has no other resources it needs to load. Furthermore, the list of requests gets cleared after each refresh (which is the default unless the setting has been changed). Not first request, but first shown request. it always misses header on alpha Does loading node information on [https://globe.torproject.org/] work for you on alpha when the header is missing? Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://onionoo.torproject.org/details?lookup=D4125249A474408F0FBA4DB15AC207E31E4CF6B3. (Reason: CORS header 'Access-Control-Allow-Origin' missing). except exitnode was changed by timeout Did the exit node change alter the responses you got? The header is always present after New Circuit. how can it reappear if algorithm states to update only when header is not missing? This could happen when you continue to refresh after you found that the header is missing. The steps are only to reproduce the missing header case. The header is always missed on step 5, so step 6 = false, why go to 4 (refresh)?

Replying to bugzilla:

Replying to cypherpunks:

Replying to bugzilla:

Oops, algorithm in comment:2 is not so plain: first request is the second actually (first was in step 1) If the Firefox Developer Tools window isn't open at step 1, the Network tab doesn't show any requests when you first open it. With the first request i meant the first one in the request list in the Network tab after the refresh at step 4. There should be only one request in this list because the page i linked has no other resources it needs to load. Furthermore, the list of requests gets cleared after each refresh (which is the default unless the setting has been changed). Not first request, but first shown request. This is what i meant, next time I'll use better wording.

it always misses header on alpha Does loading node information on [https://globe.torproject.org/] work for you on alpha when the header is missing? Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://onionoo.torproject.org/details?lookup=D4125249A474408F0FBA4DB15AC207E31E4CF6B3. (Reason: CORS header 'Access-Control-Allow-Origin' missing). This is the same error i got (see ticket description), so having that header go missing really is a problem. except exitnode was changed by timeout Did the exit node change alter the responses you got? The header is always present after New Circuit. I didn't test this before, but now that i did i see the same behavior. how can it reappear if algorithm states to update only when header is not missing? This could happen when you continue to refresh after you found that the header is missing. The steps are only to reproduce the missing header case. The header is always missed on step 5, so step 6 = false, why go to 4 (refresh)? Because previously the header didn't always go missing after the first refresh. Using a new circuit makes reproducing the issue reliable, thanks for pointing this out.

The steps to reproduce this issue reliably are now

1. Go to [https://onionoo.torproject.org/summary?limit=1].
2. Open the Firefox Developer Tools window.
3. Go to the Network tab.
4. Use a new Tor circuit for the page.
5. The Access-Control-Allow-Origin header should now be among the response headers of the first shown request.
6. Refresh the page with F5.
7. The Access-Control-Allow-Origin header isn't among the response headers of the first shown request anymore.

Replying to cypherpunks:

The steps to reproduce this issue reliably are now

1. Go to [https://onionoo.torproject.org/summary?limit=1].
2. Open the Firefox Developer Tools window.
3. Go to the Network tab.
4. Use a new Tor circuit for the page.
5. The Access-Control-Allow-Origin header should now be among the response headers of the first shown request.
6. Refresh the page with F5.
7. The Access-Control-Allow-Origin header isn't among the response headers of the first shown request anymore.

This happens in a vanilla Firefox as well and is probably related to the refresh behavior done via F5. If I reload the page with Ctrl+Shift+R I always get the Access-Control-Allow-Origin header. So, I guess this is not a bug. That said, while testing I did not encounter the "Cross-Origin Request Blocked:"-message. Thus, there might still be more to it. How can I reproduce that one?

Replying to gk:

This happens in a vanilla Firefox as well and is probably related to the refresh behavior done via F5. If I reload the page with Ctrl+Shift+R I always get the Access-Control-Allow-Origin header. So, I guess this is not a bug. That said, while testing I did not encounter the "Cross-Origin Request Blocked:"-message. Thus, there might still be more to it. How can I reproduce that one? The steps to reproduce the "Cross-Origin Request Blocked" message are somewhat similar.

1. Go to [https://globe.torproject.org/#/relay/1C90D3AEADFF3BCD079810632C8B85637924A58E].
2. Open the Firefox Developer Tools window.
3. Go to the Console tab.
4. Use a new Tor circuit for the page.
5. Refresh the page with F5.
6. A "Cross-Origin Request Blocked" message is now shown in the Console tab.

In this state Globe gets stuck with a loading animation for which i submitted #18081 (moved).

[https://bugzilla.mozilla.org/show_bug.cgi?id=1198321] and [https://bugzilla.mozilla.org/show_bug.cgi?id=1153854] describe the same problem.

Hmm, this bug is really annoying sometimes. Some sites automatically redirect to the homepage because of it.

Trac:
Keywords: N/A deleted, tbb-usability-website added

#18663 (moved) mentions that Onionoo has inconsistent header responses so maybe the problem is on Onionoo's side.

Trac:
Reviewer: N/A to N/A

Mozilla definitely has problems with that, even on its own infrastructure: https://bugzilla.mozilla.org/show_bug.cgi?id=1254742

(Another part of pre45 adventures with CORS is documented here: https://bugzilla.mozilla.org/show_bug.cgi?id=1243453)

This bug continues to appear in FF45ESR. Now it is often seen on youtube:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://r3---sn-5hnedn7y.googlevideo.com/videogoodput?id=o-ALptvSgkiq9dj8YZzEjU_IlvEja-D5U5YEWCtk6YDcPI&source=goodput&range=0-4999&expire=1460177375&ip=62.212.73.141&pl=24&sparams=expire,id,ip,ipbits,mm,mn,ms,mv,nh,pl,range,source&signature=1411C3663C76BC15F604D83CCE8B212269F36034.73E3F793170A0535E2418D142CABE082F2108EB6&key=cms1&cpn=ZN5lo-1WLQOGlNUK&redirect_counter=1&req_id=6484cc337323af3a&cms_redirect=yes&ipbits=0&mm=34&mn=sn-5hnedn7y&ms=ltu&mt=1460173716&mv=m&nh=IgpwcjAxLmFtczE1Kg03Mi4xNC4yMTcuMTcz. (Reason: CORS header 'Access-Control-Allow-Origin' missing). <unknown>

Trac:
Summary: Do not strip the Access-Control-Allow-Origin header to Firefox bug - CORS header 'Access-Control-Allow-Origin' missing

Replying to gk:

That said, while testing I did not encounter the "Cross-Origin Request Blocked:"-message. When redirect in comment:11 transforms into an endless loop, maybe, because of #18222 (moved), the message isn't shown in Console too. But it appears only once in the loop after clicking Clear, and 403 Forbidden isn't shown at all after it, probably, because of #19921 (moved). So, this all looks like previous craziness of Torbutton.

My web chat can't reconnect because of this error! It appeared right after the HTTPSE update, which was responsible for messing with headers in the past (#9481 (moved)).

When circuit visualizer has to update circuit for the site (circuit was re-requested, because the site was idle for a while), it breaks the site's WebSocket connection with this error in console.

After some time Tor Browser forgets/messes with headers of the same resources which worked before. That leads to

Error Connecting (Error: xhr poll error)

(refreshing doesn't help, new circuit helps)

Trac:
Summary: Firefox bug - CORS header 'Access-Control-Allow-Origin' missing to CORS header 'Access-Control-Allow-Origin' missing
Priority: Medium to High
Status: needs_information to new
Severity: Normal to Major

HTTPSE:

2018.6.13
  * Fix CORS issues in Firefox. This bug was previously breaking embedded
    videos or css on many websites. Chrome browser was not affected by this
    bug

Replying to cypherpunks:

HTTPSE: {{{ 2018.6.13

• Fix CORS issues in Firefox. This bug was previously breaking embedded videos or css on many websites. Chrome browser was not affected by this bug }}} The fix requires a version of Firefox higher or equal to 59, so the fix will only work when the next Tor Browser alpha is released which will be based on FF60-esr, so yeah, it's also coming in a couple of days unless . . . (You can try out Tor Browser nightly to see if the fix is popping)

Marking this as tentatively fixed in Tor Browser 8.

Trac:
Keywords: N/A deleted, ff60-esr-will-have added

Replying to gk:

Marking this as tentatively fixed in Tor Browser 8. Check https://ipleak.net/ pls.

Prio medium

Trac:
Priority: High to Medium

I'm seeing these errors on stocktwits.com:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.stocktwits.com/api/2/streams/watchlist/static.json?since=137020866&filter=top. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

This is running 8.5a1 on Ubuntu 18.04. If I click "New Tor Circuit for this Site", sometimes I'll get a few minutes of browsing before the errors come back.

Trac:
Username: rnoir

Replying to cypherpunks:

Replying to gk:

Marking this as tentatively fixed in Tor Browser 8. Check https://ipleak.net/ pls. Appears also when the Debug checkbox in NoScript is set:

01:59:42.539 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://g28kyu5u1usoie1ve5ejsyuklm7dfj1lukl0smiq.ipleak.net/dnsdetect/?_=1512910712464. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). 1 (unknown)

https://bugzilla.mozilla.org/show_bug.cgi?id=1521953

Trac:
Keywords: ff60-esr-will-have deleted, N/A added

Hello, i am seeing the error in dev. console of the latest stable and alpha (9.5a2) Tor browser when i submit login form at https://login.blockchain.com/#/login

Trac:
Username: postcd

If we can confirm steps for reproducing this and it is due to caching then we can help move 1521953 forward and get it fixed upstream.

Trac:
Keywords: N/A deleted, TorBrowserTeam201912 added

Trac:
Keywords: TorBrowserTeam201912 deleted, TorBrowserTeam202001 added

Moving tickets to February

Trac:
Keywords: TorBrowserTeam202001 deleted, TorBrowserTeam202002 added

Trac:
Keywords: TorBrowserTeam202002 deleted, TorBrowserTeam202006 added

mentioned in issue #18081 (moved)

mentioned in issue #21719 (moved)

moved to tpo/applications/tor-browser#18080