My wife's machine could not load any Instagram content through JavaScript because of the following error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://graph.instagram.com/logging_client_events. (Reason: CORS request did not succeed).

I tried getting it to work again, even went so far as to uninstalling Firefox, clearing any Mozilla related data and reinstalling it... same error (default settings, no plug-ins).

Then I noticed she had been logged out of the VPN service (just a commercial VPN service), so I logged her in without giving it much thought. Try Instagram again and... problem solved.

I tried to repeat the above on my own machine, same story:

  • VPN service enabled -> everything works just fine.
  • VPN service disabled -> CORS requests for Instagram fail.

My Question(s):

  • Is there any common explanation for this behaviour?
  • Could this point to a compromised router or strange ISP activity?

Background info:

  • Our current router is a common DSL router/modem supplied by our ISP,
  • Without the VPN, the connection is a plain and simple consumer setup, without any special configuration or routing.

I've noticed the same issue when accessing Instagram via my own ISP.

The culprit is found in the response headers received from Instagram, which contain the following policy:

access-control-allow-headers: ...

This policy checks for specific headers to be specified for content. In my case, the header: "x-ig-www-claim" is missing which causes a number of requests to fail, and a Failed to load message to appear.

This, on its own suggests that Instagram has misconfigured something on their website, but when testing via my 4G data connection, no errors are shown. The machine, browser and installed software remain the same.

When accessing via 4G, I no longer receive any access-control-allow-headers policy, or any other access-control-methods. There's no filtering on the origin anymore, therefore all requests work.

It's not clear to me why the headers are present via my ISP and missing via 4G, but I'd be interested in knowing if this matches with what you are seeing. Could you confirm?

  • Where is the X-Ig-Www-Claim header missing from? Is it in the requests, but not listed in Access-Control-Allow-Headers? – Anders Sep 10 at 8:51
  • Example error: Access to XMLHttpRequest at 'z-p4.www.instagram.com/ajax/bz' from origin 'instagram.com' has been blocked by CORS policy: Request header field x-ig-www-claim is not allowed by Access-Control-Allow-Headers in preflight response. Checking the request headers, the x-ig-www-claim header is indeed in the Access-Control-Request-Headers. – Mike Sep 10 at 19:04
  • Update: checked request headers via 4G and the x-ig-www-claim is sent as a separate header in this format: x-ig-www-claim: 0 – Mike Sep 10 at 19:11

For some web applications, your browser store session cookies that is used for authentication and setting sessions between your machine and the server.

Attackers can sends the same session cookie, and gains authenticated access to your account on the server by spoofing your identity and tricking the server to be you.

The error is showing for you is a solution for this problem. It is used to push back browsers implementation called the same-origin policy which is used to avoid cross-site request forgery (CSRF). Therefore it does not mean you have a compromised router or strange ISP activity.

The only trouble is that the browser automatically includes any relevant cookies stored for a domain when another request is made to that exact domain.

The standard solution for this is actually to just proxy your request, so that they're hitting from the same origin. That is why when you enabled the VPN it worked, since it is using a different proxy for the web requests that you have made.

  • While what you write is true, it does not apply to the scenario described. The behaviour is persistent across machines and across full (clean) reinstalls of the browsers. – Jacco Aug 28 at 16:11
  • I think you need to find a way to locate and clear the Server side cookie that is saved on your browser and check again if you have the same error - only to be sure and assuming it is truly saved on your browser. – Hussain Mahfoodh Aug 28 at 16:46
  • This answer is incorrect. A VPN on your end isn't the kind of proxying that affects CORS – Joseph Sible Aug 28 at 21:36
  • @JosephSible Could be a proxy VPN is used in this question. – Hussain Mahfoodh Aug 29 at 3:13
  • @HussainMahfoodh even a "proxy VPN" wouldn't make this answer correct. – Joseph Sible Aug 29 at 4:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.