2

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.
Improve this question

2 Answers 2

Reset to default
2

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?

Improve this answer
3
  • Where is the X-Ig-Www-Claim header missing from? Is it in the requests, but not listed in Access-Control-Allow-Headers?
    – Anders
    Commented Sep 10, 2019 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
    Commented Sep 10, 2019 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
    Commented Sep 10, 2019 at 19:11
-1

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.

Improve this answer
10
  • 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
    Commented Aug 28, 2019 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
    Commented Aug 28, 2019 at 16:46
  • This answer is incorrect. A VPN on your end isn't the kind of proxying that affects CORS
    – Joseph Sible-Reinstate Monica
    Commented Aug 28, 2019 at 21:36
  • @JosephSible Could be a proxy VPN is used in this question.
    – Hussain Mahfoodh
    Commented Aug 29, 2019 at 3:13
  • 1
    @HussainMahfoodh obviously, yes, something is different, or this wouldn't be a question. I just disagree with your answer as to what the "something" is.
    – Joseph Sible-Reinstate Monica
    Commented Aug 29, 2019 at 13:33

You must log in to answer this question.

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