I was working on a userscript today, which had a goal of displaying chat pings immediately at the main site. This would allow me to respond more quicker-like to chat pings.
However, I was met by this fearsome warrior:
Can we please set some decent header things? I want to be able to do this really bad.
Certainly not. We're not going to allow CORS for pages that require (or at least change with) authentication. Even with origin restrictions, this would need a very good reason, and "I want to be able to do this really bad" isn't one (and calling this a "bug" is pretty far out there).
Here's a tip though: User scripts can run on more than one page and do different things depending on what site they're running on, and then there's postMessage.
A real-world use case for making such requests is fetching post titles to help chat users use Markdown-formatted links in messages (and avoiding one-boxing — which is considered bad etiquette by many rooms at least on Stack Overflow — to get meaningful titles) without resorting to using the API for each and every post.
It does not have to be the overly permissive (and opening a whole can of worms) "allow-all header":
Access-Control-Allow-Origin: *
It would be of great help to userscript authors that need their scripts to make cross-origin requests at least between sites of the Stack Exchange network. For example, currently, it is impossible to make a request to *.stackapps.com from *.stackoverflow.com because the access control header is not set on responses.
I realize that since Access-Control-Allow-Origin (see spec) can only allow one origin (unless the value is the wildcard), it will require the backend to maintain a list of allowed Origin (see MDN) request headers and echo it if the latter is in the list, so the request is just to reconsider the decision made more than 7 years ago.
Userscripts have the userscript APIs, specifically GM_xmlhttpRequest and GM.xmlHttpRequest, which allow making cross-origin requests – Makyen 2 hours ago
While this is indeed possible, usage of GM_* functions makes userscripts dependent on being run via the manager (whereas with either fetch or XMLHttpRequest the script does not depend on one), as well as incurs maintenance cost (for example, not as popular as it used to be but still used Greasemonkey has an asynchronous API and exposes the functions as methods on a global GM object instead).
GM_xmlhttpRequest and GM.xmlHttpRequest, which allow making cross-origin requests. While it might be easier if using those wasn't required. It's not something which you are completely prevented from accomplishing. There are also other possible ways which you could make such requests with a userscript.
@grant headers needed to use GM_* functions.
GM_xmlhttpRequest and GM.xmlHttpRequest, because those are asynchronous calls in all userscript managers due to the (primarily) inherent asynchronous nature of network requests. In other words, there's very little difference for using the basic functionality of that API across different userscript managers. Requesting both of those APIs and choosing to use whichever one is actually available is a couple lines of code.
@grant none vs. the environment when you ask for one or more of the userscript APIs. That can substantially change/increase how one has to interact with the page scripts. So, yes, it would be more convenient to be able to make native cross-origin requests from within other SE sites, but it's not something that needs to happen.
GM_* and GM.* functions ties the script to using a userscript manager and makes the author either account for the differences in exposed APIs or choose to explicitly not support one of the managers. By stressing the async vs sync difference I just pointed out that there are differences in exposed APIs, and the burden of reconciling them is placed on the userscript developer even if all they wanted is to make cross-origin requests "inside" the SE network.
GM_xmlhttpRequest and/or GM.xmlHttpRequest isn't necessary in order to accomplish what you want. As was implied in the original answer here, it's also quite possible to create an iframe and pass messages back and forth from the instance of your userscript running in the current page with an instance of your script running in the domain within which you wish to make requests/get data (e.g. just pick some URL to a 404 page for your script's use and run on that page).