IOS 10.3.1 Chrome browser CORS fail

Question

I ve been experiencing a strange error while doing CORS requests from my website (React app talking to APIs over https). The errors appear only on IOS 10.3.1 and on the Chrome browser (57) (safari and webViews are fine). Due to the lack of tools to debug IOS Chrome the only record I have is what Sentry logs (3rd party service). The errors are variations of:

SecurityError Blocked a frame with origin "https://xxxxxreactapp.com" from accessing a frame with origin "https://xxxxx.fls.doubleclick.net". Protocols, domains, and ports must match.

The specific request is fired from the Google Tag Manager, but requests to my own API fail in a similar fashion (though obviously without mention of frames but still cross-origin related).

A typical request handshake to my own API looks like:

OPTIONS /jp/plusbus HTTP/1.1
Host: api-xxxxxx.xxx.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Request-Method: POST
Origin: https://xxxxxreactapp.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Access-Control-Request-Headers: content-type,x-access-token,x-trace-token
Accept: */*
Referer: https://xxxxxreactapp.com/xxxx/xxx
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8,el;q=0.6

and the server response to that:

HTTP/1.0 204 No Content
Connection: close
Content-Type: text/html
Access-Control-Max-Age: 1728000
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,PATCH
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,X-Access-Token,X-Customer-Token,X-Customer-Device,X-Brand-Id,X-User-Token,X-User-Grant-Token,X-Trace-Token,X-Smartcard-Version,Authorization
Content-Length: 0

This describes interaction between the App and the API which I both control, I m tempted to think something is wrong with my setup but 2 things lead to a different conclusion:

• I m also using the Google Tag manager on the same site, its requests also fail in the same way (the GTM uses a standard iframe setup which also attempts CROSS-ORIGIN communication).
• This setup was stable all the way till the last IOS update, it all works properly in IOS 10.2

UPDATE

Managed to sort out the api calls, it was something to do with my proxy middleware stack. BUT the 3rd party problem is still not resolved.

All tools that rely on iframes to communicate data over to external sources fail with the above mentioned SecurityError Blocked a frame .... That includes the GoogleTagManager and Paypal payments

Furness

FWIW, we're logging production exceptions and noticed that after the iOS 10.3 update on March 23rd, our error rate for this exception ("Security Error: Blocked a frame...") increased significantly: i.imgur.com/QDDFs8Z.png – Formation

FYI I'm hitting the exact same issue and I'm also getting the errors logged via Sentry. – Dudleyduds

@DavidGomes Are you also using Google Tag Manager? – Formation

No, it's another service that also uses iframe for cross-origin communication (Keycloak). We also can only replicate on iOS 10.3. So I looked at the security release notes for this OS update and they changed a bunch of things that are related to CORS. However, at first sight, it didn't seem to me like any of them should break this functionality, especially because it works elsewhere. – Dudleyduds

Have you tried using Content-Security-Policy? developers.google.com/web/fundamentals/security/csp – Rarefied

chromium issue: bugs.chromium.org/p/chromium/issues/detail?id=709132 – Hehre

Have you tried setting Access-Control-Allow-Origin to https://xxxxxreactapp.com rather then a * in your server response – Schall

Not an option since its a public api its meant to be accessed more than my app. – Furness

@Furness does the below answer answer your question? It looks like the 'Blocked a frame' error continues to be an unaddressed issue in iOS Chrome. – Hehre

I m not sure, does it? I mean I know its still not resolved, but with no fix or workaround this can not be considered resolved. The very least this issue will be affecting GTM setups (as well as other 3rd party tools that use iframes in this way) that run on mobile chrome. These are major tools that fail for an important percentage of IOS users. Can we say its enough that 'we know theres a problem'? – Furness

I wonder if GTM/3rd party trackers are actually failing. We know they are causing this error; are you certain they are actually failing? The example below suggests that cross-domain iframe communication still works even though this error is thrown. – Hehre

Good point, originally I had a listener on the window.error for errors that bubbled up all the way unhandled, which in turn poped up an overlay blocking users from using the app just in case something had gone horrifically wrong. I m filtering for that specific error now so users are using the app, so will have to check wether I m actually getting data send to the GTM from this combo of browser/IOS. If thats the case it ll mean its actually working even though its throwing the error – Furness

@Furness the chromium issue is fixed and should be released in the fall, according to the linked issue. – Hehre

Answer 1

Specifically regarding the iframe issue, it appears that this error is related to Chrome autofill. You can reproduce the error using the sample code provided in comment 6 of the associated chromium issue (worth reading all the way through):

<body>

  <iframe src="http://example.com">
  </iframe>

  <script>

    window.addEventListener("error", function (e) {
       alert("Error occured: " + e.error.message);
       return false;
    });

  </script>
</body>

If you open this page in iOS Chrome, it will pop an alert with the above error. If you go to Chrome Settings, turn autofill off, and reload the page, the error is gone. This is tested with iOS 10.3.1 and Chrome version 58.0.3029.113.

There does not appear to be a solution at this time, but it appears that the content in the iframe does load successfully even with the error. As such, there should be no discernable impact on the end user.

Hehre