I have tested this item ✅ successfully on 1fdfbb9

Hints for other testers:

1. It needs to run npm ci or npm run build:js after having applied the changes from this pull request in order to rebuild the JS in the media folder, or you use the installation or update package or custom update URL created by drone.
2. You can easily test the PR using the developer tools of your browser. E.g. in Firefox Developer Tools on a page of the site to be tested, the "Console" tab allows to enter and run the JS code provided in the description of this PR, and in the right part you can see the request and response (a 404 if you don't have a "com_example" installed, buit that's ok because not relevant for the PR), and you can examine the request header.

   ---

   _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39343.}

P.S.: In addition to the 2 test cases provided in the description, I have also tested:

Joomla.request({
  method: 'POST',
  url: 'index.php?option=com_example&view=example',
  sendCsrfToken: true
});

I have tested this item ✅ successfully on 1fdfbb9

RTC

Sorry to be late but I think this is more appropriate

I think we should consider Dimitris PR, it will work automatically.

thanks for your work but I'm closing this in favor for #39580

@HLeithner I think this one should be merged too as well as dimitris' one. because although that PR works automatically for external sites we'd still leak csrf tokens into subdomains (e.g. imagine an elasticsearch instance or another Joomla setup or even a mastodon instance or something) whereas with explicit code here we will not.

Probably replace sendCsrfToken: true, with skipToken: false,

and the code from my PR with the change:

// Use the CSRF only on the site's domain
 // eslint-disable-next-line no-restricted-globals
 if (!newOptions.skipToken && token && (newOptions.url.startsWith('/') || newOptions.url.startsWith(location.origin))) {
   xhr.setRequestHeader('X-CSRF-Token', token);
 }

in this case the other pr should be fixed that it's only valid for the joomla domain and not the subdomain. but of course would it leak into subdirectories which are not joomla but at some point I think it will be hard to differ for us what is joomla and what is external

Great, because more crappy automagic code is what everyone needs ?‍♂️. It's funny because neither @dgrammatiko nor @Fedik objected to the leak being introduced in the first place in #14952. So why start caring now? The idea behind introducing a parameter is that it allows the behavior to be deprecated in a predictable and documented way. Eventually, the magic behavior should be removed and the token should be explicitly passed by the caller along with the other headers.

Eventually, the magic behavior should be removed

Actually, the Joomla.request() should be immediately deprecated and replaced by fetch() without any magic Joomla wrapper. The MDN docs are far better than any documentation ever written about anything front end/back end on this project.

BTW I'm totally fine closing my PR and letting you drive the changes here, my intention wasn't to hijack your PR but rather invert the logic to stop the leak for foreign domains (which is the real problematic part)...

objected to the leak being introduced in the first place

Note: by default cross origin requests is blocked by browser, you need to do some extra job to make such leakage work.