Modern browsers prevent scripts fetching RSS feeds from sites out of the domain of the running script. The RSS feed gets transmitted but the browser's Same Origin Policy won't let you access it. Only feeds from servers that specify the CORS Access-Control-Allow-Origin header can be read.
Why?
We are not talking about malicious scripts - just XML data. What is the thinking behind considering an RSS feed as a potential danger? How could it be exploited?
Only feeds from servers that specify the CORS Access-Control-Allow-Origin header can be read.
so all major web-browsers implement a blanket block just so that insecure servers don't leak otherwise publicly available feeds? Still does not make much sense to me.
By default, the Same-Origin Policy won't let a client read the response to a cross-origin request, regardless of whether the requested resource is publicly accessible. CORS is a protocol for the server to instruct a browser to selectively relax some of the Same-Origin Policy's restrictions (both in terms of reading and sending) on network access to a resource from some requesting client.
There's nothing special about an RSS feed. In the case you describe, it's just one cross-origin resource among others. Carving out an exception for RSS feeds in the SOP would have needlessly complicated it.
The RSS can still be downloaded using a download manager or even wget. That does not make any sense.
True, but the SOP was never meant as a substitute for server-side access control; for one thing, it's only enforced in browsers, not in other user agents like curl or Postman. Rather, the SOP is meant to protect Web origins from one another.
why is RSS data considered dangerous?
We are not talking about malicious scripts - just XML data. What is the thinking behind considering an RSS feed as a potential danger? How could it be exploited?
You've got it backwards. The SOP's restrictions on network access are not meant to defend the client against a malicious resource. Instead, they're meant to defend the resource against a malicious cross-origin client, which might for example attempt to exfiltrate data from the resource.
If you control the resource in question, you can override the default behaviour of browsers and configure CORS to allow clients from any Web origin to read the response from the requested resource.
ajax preceded CORS by several years. Ajax W3C Standard 2006; CORS W3C Standard 2014. I know I was programming way back then!
Support for cross-origin requests with AJAX only came later than 2006, prompting the need to devise the CORS protocol. See XMLHttpRequest Level 2, W3C Working Draft 25 February 2008:
XMLHttpRequest Level 2 enhances XMLHttpRequest with new features, such as cross-site requests [...]
(my emphasis)
Note that "cross-site" should be understood as "cross-origin", here. The difference matters now that "site" has a more technical meaning.
Besides, CORS support was added to major browsers in the later 2000s. It didn't wait until the 2014 W3C standard.
