Customer issue: "Blocked a frame with origin <hostname> from accessing a cross-origin frame."

[ryan953]

Private ticket with customer info: https://getsentry.atlassian.net/browse/FEEDBACK-1689

The customer is getting this "Blocked a frame with origin from accessing a cross-origin frame" error which is preventing any replay from being captured.

[m-nathani]

The same issue is happening on my side as well

[Lms24]

I tried to reproduce this by adding an iframe to a small plain-JS test app of mine. I pointed it to various 3rd party websites and noticed that these "Blocked a frame" and a few other CSP errors only occur on some websites. So my guess is that this might be rather specific to certain websites that perhaps somehow test if they're used in an iframe?

@m-nathani could you elaborate a little on what's happening for you? For instance how you're using iFrames and how the error message looks for you. Also, does this error crash replays for you, too? Or is it just an error that's being logged to your console?

[Lms24]

@m-nathani I'm realizing, you already told me about your setup here, right? So I'm wondering if this is only an issue in situations where replay is used inside an iframe and not the base site.

[m-nathani]

@m-nathani I'm realizing, you already told me about your setup here, right? So I'm wondering if this is only an issue in situations where replay is used inside an iframe and not the base site.

@Lms24 it appears that the error i faced on the websites does not use replay inside an iframe.

This is exact error i faced using 7.28.1:
https://sentry.io/organizations/umai/issues/3808100150/?project=5264087&referrer=slack

Failed to read the 'contentDocument' property from 'HTMLIFrameElement':
 Blocked a frame with origin "https://letsumai.com" from accessing a cross-origin frame.

This is the site address which cause this error. Furthermore, you can check in the chrome dev tools Elements tab that the only iframe used in it for stripejs which we are using internally for payments.

Addiotnally, for the issue mentioned here, would appreciate if can help me resolve, as i am still facing it 🙏🏼

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[m-nathani]

The issue still happens, check here for details: https://sentry.io/organizations/umai/issues/3808100150/?project=5264087&referrer=slack

[Lms24]

I'm not sure if I'm missing some crucial information here but according to your description in #6542, your app is a modal that is embedded in your clients' websites. As we saw in #6542, the Replay integration interacts with your host website as it's accessing the base website's hub. So in this case, I can imagine that the browser detects a coss-origin frame access which could explain the error.

Something else I came across while checking your last linked error: There appear to be two script origins (https://letsumai.com vs widget.letsumai.com). Any chance that this is in fact responsible for the cross-origin access?

[m-nathani]

Yeah its possible for embedded clients website's hub conflicting with ours. However as discussed #6542, we can't do anything about it yet...

Thanks for highlighting for (https://letsumai.com vs widget.letsumai.com), i need to check on it. However, it's working for most of embedded sites, so need to dig more if these could be a issue.

[Lms24]

Also, as mentioned in #6542 (I know, you know this already, but just for transparency), I want to mention that Replay currently (and in the forseeable future) doesn't support partially recording a web site or similar multi-hub/origin scenarios. I'm afraid, there's nothing we can do here at this time.

cc @bruno-garcia I suggest we close this issue for the time being and re-open, if we get more cross-origin iframe error reports. wdyt?

[jirizavadil]

Hi @Lms24, i'm getting these:

when using firebase/auth
Blocked a frame with origin "https://tralala.la" from accessing a frame with origin "https://tralala-project.firebaseapp.com". Protocols, domains, and ports must match.
&
when using @stripe/stripe-js
Blocked a frame with origin "https://tralala.la" from accessing a frame with origin "https://js.stripe.com". Protocols, domains, and ports must match.

Both inject an iframe inside body. When i remove Sentry.Replay() from integrations in Sentry.init(), both disappear.

I'd be more than happy if i could just tell Replay to ignore these frames/origins, as i don't care what happens inside, because it wouldn't be rendered anywhere anyway.

Ideas?

[pfdzm]

Hi @Lms24, i'm getting these:

when using firebase/auth Blocked a frame with origin "https://tralala.la" from accessing a frame with origin "https://tralala-project.firebaseapp.com". Protocols, domains, and ports must match. & when using @stripe/stripe-js Blocked a frame with origin "https://tralala.la" from accessing a frame with origin "https://js.stripe.com". Protocols, domains, and ports must match.

Both inject an iframe inside body. When i remove Sentry.Replay() from integrations in Sentry.init(), both disappear.

I'd be more than happy if i could just tell Replay to ignore these frames/origins, as i don't care what happens inside, because it wouldn't be rendered anywhere anyway.

Ideas?

We have a similar issue in our setup, Replay seems to want to peek into any other frame embedded in our page - would it be possible to whitelist only specific frames/origins for Replay to hook into?

[billyvg]

@jirizavadil @pfdzm You should be able to use block with a selector that targets the iframes in question. Alternatively you can add data-sentry-block attribute to the iframe.

[jirizavadil]

@billyvg Sentry.replay({block: 'iframe'}) did the trick. For some reason this wasn't clear to me from the docs wording and was looking for something like 'ignore'.
Thanks!

[billyvg]

@jirizavadil Glad to hear -- I'm assuming that snippet is a typo? block should be an array.

[jirizavadil]

@billyvg well... 😅 yeah, let's call it a late night typo. But it ain't stupid if it works, right? 😂

[mydea]

Maybe we should by default block all iframe, and allow users to opt-in into capturing (first-party) iframes. As currently the experience is not ideal with iframes... maybe a captureFirstPartyIframes option or something along these lines?

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[JarnoLeConte]

It's a problem with the Replay package and Safari web browser. Safari is blocking the replay's actions on iframes. When I enable the Replay integration, the following errors appear on my site:

[Error] Blocked a frame with origin "https://shimejis.xyz" from accessing a frame with origin "https://consentcdn.cookiebot.com". Protocols, domains, and ports must match.

[Error] Blocked a frame with origin "https://shimejis.xyz" from accessing a frame with origin "https://googleads.g.doubleclick.net". Protocols, domains, and ports must match.

[Error] Blocked a frame with origin "https://shimejis.xyz" from accessing a frame with origin "https://auth.shimejis.xyz". Protocols, domains, and ports must match.

[Error] Blocked a frame with origin "https://shimejis.xyz" from accessing a frame with origin "https://tpc.googlesyndication.com". Protocols, domains, and ports must match.

[Error] Blocked a frame with origin "https://shimejis.xyz" from accessing a frame with origin "https://www.google.com". Protocols, domains, and ports must match.

[Error] Blocked a frame with origin "https://shimejis.xyz" from accessing a frame with origin "https://googleads.g.doubleclick.net". Protocols, domains, and ports must match.

I do not control these dynamically created iframes and are not able to mark them with a data-sentry-block attribute. Also adding the selector iframe and [src] to the Replay configuration does not make any difference.

Sentry.init({
      dsn: 'XXX',
      replaysSessionSampleRate: 0.001,
      replaysOnErrorSampleRate: 1.0,
      integrations: [
        new Sentry.Replay({
          maskAllText: true,
          blockAllMedia: true,
          block: ["iframe", '[src]'],
        }),
      ],
    });

These errors are not logged in Google Chrome.

I hope this issue will be fixed, because I don't want to make use of a package that is logging errors.

[bourquep]

@billyvg Sentry.replay({block: 'iframe'}) did the trick. For some reason this wasn't clear to me from the docs wording and was looking for something like 'ignore'.
Thanks!

This does not work for me, unfortunately.

[mydea]

@billyvg Sentry.replay({block: 'iframe'}) did the trick. For some reason this wasn't clear to me from the docs wording and was looking for something like 'ignore'.
Thanks!

This does not work for me, unfortunately.

Could you open a new issue with details on your setup & what is not working?

[bourquep]

I am not 100% sure my bug is with Sentry, but I'll open a new issue if I ever confirm.

[Talb2005]

I'm also getting this error in my Angular app.
This error occurs only on Safari and only when Sentry replayIntegration is enabled.
Blocked a frame with origin <hostname> from accessing a frame with origin "https://www.googletagmanager.com". Protocols, domains, and ports must match.
Adding block: ['iframe'] to the ReplayConfiguration doesn't make any difference.

[Talb2005]

Ok I now managed to solve it.
Instead of block: ['iframe'] I used the iframe id as the selector block: ['#GTMiframe'] and now the error is gone. :)

[jakst]

I'm seeing these errors with Sentry replayIntegration together with Stripe. I have had no success with block: ['iframe'] or targeting any of the HTML attributes of the iframes. The iframes that Stripe generates have no stable identifiers, so I can't use an ID or class. I tried more involved targeting like [src*="stripe.com"], but to no avail.

Anyone had any luck with getting rid of these errors with Stripe? This is a Safari only issue like others in the thread have mentioned.

Blocked a frame with origin "https://our.domain.com" from accessing a frame with origin "https://js.stripe.com". Protocols, domains, and ports must match.

[HofmannZ]

@billyvg & @mydea - I'm confused about why this issue was closed. We have Firebase and Stripe generating iframes on our page, which we can't block. At the moment, there doesn't seem to be a viable solution for Safari.

[mydea]

I guess this flew under the radar because it was already closed - in the future, please just open a new issue in such cases, if you are still experiencing an issue for something that was previously closed, then it is easier for us to keep track of this!

We'll need to look more into this, we're quite busy at the moment but will hopefully have some more time on our hands to investigate this further soon!

[jakst]

I found a workaround, that is not optimal, but at least works for our use case where the iframes are only present on some pages.

What I do here is block the whole body element whenever there's an iframe on the page with a name containing the value Stripe.

block: ['body:has(iframe[name*="Stripe"])']

This works for us, since Stripe is only mounted on the payments page. That means we got no replays on the payments page. But for iframes that need to be mounted on every page this workaround will not work, unfortunately.

[mydea]

I think @billyvg identified the problem and has a possible fix for it in the works! 🎉

[jakst]

@mydea @billyvg how do I follow the release status of rrweb#201? I can't figure out how the rrweb repo relates to the sentry-javascript repo

[mydea]

It will be part of the release notes of sentry-javascript, and hopefully in the next/an upcoming release!

[jakst]

I tried out the latest release (8.22.0) with our app, but the issue isn't fixed for us. I created a new issue with a minimal reproduction, since this issue was closed. #13173