Setting Origin: null header still breaks CORS in Tor Browser 9.5

I'm working on creating an onion service version of theintercept.com using Alec Muffet's EOTK (https://github.com/alecmuffett/eotk) and running into an issue with CORS that lead me to legacy/trac#32255 (moved). The patch that fixed that issue doesn't totally solve the Tor Browser CORS problems.

Specifically, embedding documents from DocumentCloud works in Tor Browser 9.5 on the clearnet site, but breaks when viewing my test onion site. Here is an example document: https://theintercept.com/document/2019/05/08/ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-protest-surveillance/

This page makes a XHR request to https://www.documentcloud.org/api/documents/5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json with the following relevant request headers:

Origin: https://theintercept.com
Referer: https://theintercept.com/

And the response has these relevant headers:

access-control-allow-credentials: true
access-control-allow-headers: Accept,Authorization,Content-Length,Content-Type,Cookie
access-control-allow-methods: OPTIONS, GET, POST, PUT, DELETE
access-control-allow-origin: https://theintercept.com

The response body is JSON object that describes the document. This page ends up working fine. After loading that XHR request, it makes a series of other requests to assets.documentcloud.org, loading images for individual pages of the document to display.

I've configured EOTK to basically run two onion services, one that proxies requests to theintercept.com (ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion) and one that proxies requests to documentcloud.org (5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion). (Note that both of these domains force HTTPS and use a self-signed certificate, so if you want to test them you'll need to accept the untrusted certificates.)

Here is the onion service version of that page: https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08/ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-protest-surveillance/

This page makes an XHR request to https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion/api/documents/5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json with the following relevant headers:

Origin: null

(Tor Browser is stripping the Referer header.)

And the response includes these relevant headers:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Accept,Authorization,Content-Length,Content-Type,Cookie
Access-Control-Allow-Methods: OPTIONS, GET, POST, PUT, DELETE
Access-Control-Allow-Origin: null

The response body is blank, and this warning is in the Tor Browser console:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqi…5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json. (Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘null’).

Note that if I configure EOTK to only create an onion proxy for theintercept.com, and not for documentcloud.org, I get the same behavior.

One possible solution would be to treat onion sites that load resources from other onion sites different than onion sites loading resources from clearnet sites. When it's onion -> onion, it could send the actual Referer and Origin headers, but when it's onion -> clearnet, it could strip the Referer header and send Origin: null, which is the current behavior.

For example, if https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08/ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-protest-surveillance/ makes a request to https://www.5h2y2fecwejfrizmzdt2bmwxvykv32xddx4k4f2lhocgvxqiwsabm2qd.onion/api/documents/5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json, it would send these headers:

Origin: https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion
Referer: https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/

However if https://ef2a2y3w5caq5vwk5e44kop2esfie5xc4jankrbydv6yeiy3uhpy7eid.onion/document/2019/05/08/ron-wydens-letter-to-private-intelligence-firm-lookingglass-on-immigration-protest-surveillance/ makes a request to https://www.documentcloud.org/api/documents/5993383-Ron-Wyden-s-Letter-to-Private-Intelligence-Firm.json, it would send these headers:

Origin: null

But also, in the case of The Intercept's website, I don't think it's a problem to leak the domain name in the Origin header when making requests to DocumentCloud, and in fact it would be nicer to not have to use a separate documentcloud.com onion proxy at all. I believe it would "just work" if the Origin header were passed as expected. So, another possible solution would be if an onion site could somehow tell Tor Browser that it doesn't want the Referer or Origin headers to be modified, maybe using an http header or something?