I'm consuming OData services from JQuery and running into a typical scenario of Same Origin Policy. I do not have control over the server and therefore I can not implement CORS so the only thing I can do is to use a proxy in order to bypass the same origin policy. In particular I use cors-anywhere. But I tried others and still having the same issue.

So, anyway, until then it is all cool, I'm able to save the situation with the proxy and to execute my ajax call with no problem, but, this only works for GET requests. Because, now the server also requires a CSRF token for POST, PATCH, etc and it looks like the token I obtain through a call to the server through the proxy:

resuest csrf

is not valid for my next consecutive requests to the server. Moreover, I notice that every time I request a CSRF token like this(http://localhost:9191/https://my-server) I obtain a different one, which is not happening if I do the request without using the proxy(https://my-server). So, my question is:

Would anyone be able to explain why this is happening and if so, is there any way to overcome this problem in order to be able to make requests from JS?

So far I've tried a number of things such as rewriting Host, Referrer, Origin and other headers in the proxy without success and though I could really use some help from this wise community here. Any comments or suggestions welcome.


  • 2
    You probably need the withCredentials option on the XMLHttpRequest, and Access-Control-Allow-Credentials in the server headers
    – paj28
    May 19, 2017 at 19:39
  • Could you try to pass some traffic captures here? From client-proxy and proxy-server communication? Its hard to tell something without such information.
    – Fis
    May 26, 2017 at 17:46
  • Are you sure the token you add to headers on client side correctly passes the proxy including referrer and/or origin headers?
    – Fis
    May 26, 2017 at 18:03

2 Answers 2


I'm not sure if this applies in this case but I thought it may be useful to some people.

CSRF tokens are sometimes rejected because each consecutive request doesn't preserve the cookies which were set on the previous request. This is likely because the CSRF token is either stored as its own cookie or more often, inside a session cookie which will change if Set-Cookie is ignored.


As far as I can tell, it sounds like cors-anywhere is caching the CSRF token when it should not be. I would run wireshark on your node server, and confirm that your requests are being forwarded on to the target server every time.

If that doesn't work, I would try running cors-anywhere on a different machine. I've seen some unexpected behavior with cookies from browsers when using local host, and there might be something similar happening with request headers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .