0

I am trying to write an RSS feed consumer in JavaScript, but unfortunately most feeds do not seem to explicitly set an access-control-allow-origin header on their responses (Even though it is my understanding that the data is for public consumption / scraping).

My question is: Is there a way to load data like this in javascript (Aside from using a server side proxy or turning the project into a browser plugin) given that:

  • The requests are simple get requests. (So no OPTIONS request would normally be sent even if the access-control-allow-origin header was present)
  • Cookies / Authentication is not important as the feeds are public. (So withCredentials would be false if it were an XMLHttpRequest)

e.g. Something like:

fetch('http://rss.slashdot.org/Slashdot/slashdotMain', {
  crossOrigin: false,
  xhrFields: {
    withCredentials: false
  }
})).then(function(response){
  console.log('Got a response!', response);
});

Update

The second part of my question is: Why is this not allowed?

For example: Suppose I for whatever reason navigate to a domain malicious-website.com. It sends a simple Ajax GET request including withCredentials: false to my-bank.com. my-bank.com processes this request, but then the browser blocks the response.

How does blocking the response to this get request improve security?

  • It does not matter if I am logged in to my-bank.com in a different tab, as no cookies or authorization header is send as per the withCredentials: false directive. The classic XSRF scenario has already been prevented - this request is exactly as if any other user on the internet [including a malicious one] had loaded this resource.
  • If there was an authentication token in the URL (Such as JWT) then malicious-website.com already has this and can potentially store it for their own use later - blocking this particular response does not change this.
  • It does not protect the data on my-bank.com since it does not block the request, just the response - if they have a REST style resource that performs an update in response to that GET then I am going to have a bad time. i.e.: The classic CSRF is not prevented unless my-bank.com requires a non simple request on updates (A POST or request with headers so that an OPTIONS request is sent first)

So again, what good does blocking just the response actually do here?

I guess the answer I was looking for was along the lines of: "If simple withCredentials: false requests were also allowed to subvert the same origin policy then a bad actor could do X".

Any ideas on what that X is?

halfer
  • 19,824
  • 17
  • 99
  • 186
tofarr
  • 7,682
  • 5
  • 22
  • 30
  • 1
    CORS is meant to be consumed by browsers (or other implementing user agents) to protect users of one domain from having their requests diverted to another (an attack that was common before CORS). Forcing an implementer to use a server-side proxy means that the implementer has taken on the risk burden for any malicious code that might get to users of their domain. – Heretic Monkey May 22 '19 at 21:44
  • I am not sure what you mean by "having requests diverted to another domain". How are requests diverted? Do you mean by script injection, or by a malicious website? Given a situation where cookies and authentication are blocked, how would this threaten the user? – tofarr May 23 '19 at 12:35
  • You can read all about CORS on the internet. The [W3C page on CORS for Developers](https://w3c.github.io/webappsec-cors-for-developers/) gives a good explanation of the reasons and history as to why it was created. The [standard itself](https://www.w3.org/TR/cors/) goes into detail on the mechanics. You might also look at other questions on Stack Overflow; for instance, over in the Related section of this page is [Is CORS a secure way to do cross-domain AJAX requests?](https://stackoverflow.com/a/4850752/215552) which goes into some of these questions. – Heretic Monkey May 23 '19 at 12:46

0 Answers0