Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

SharedArrayBuffer in an Iframe

So SharedArrayBuffer was recently limited to Cross-origin isolated pages as a security fix.

We have a tool that depends on SharedArrayBuffer, I reworked it to work again by moving it to a barebones page stripped of all other site UI and what not and sending the following headers:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Trying to load it in an iframe of the full-fledged site gives me the console errors SharedArrayBuffer will require cross-origin isolation as of M92 followed by ReferenceError: SharedArrayBuffer is not defined - same as I was getting before I cross origin isolated the tool on the minimal page itself.

The page I'm trying to include the iframe in is not cross-origin isolated. It would be very difficult if not impossible to do so. I don't need to talk to the iframe from the parent page at all, it's just a convenience/stylistic thing. The current solution on production right now is just to link users to the minimal cross origin tool page in a new window, but that's pretty awkward.

What I'm hoping is that there is some combination of iframe sandbox attributes or something that would make this work? I fought with this for a couple hours.

This may not be doable for all I know.

like image 422
donatJ Avatar asked Aug 16 '26 01:08

donatJ


1 Answers

Try adding allow-scripts and allow-same-origin tokens in the iframe's sandbox attribute:

<iframe src="…" sandbox="allow-scripts allow-same-origin"></iframe>
                         ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^

Here are some relevant resources on the topic:

  • Sandboxing, IFrame, and allow-same-origin (StackOverflow question)
  • Securing an iframe thanks to the sandbox attribute
  • <iframe>: The Inline Frame element (MDN docs), – don't miss the Note about security in the attribute's description.

Try the above first, and if it didn't help with the SharedArrayBuffer problem you have, then things are a bit more complex.

Proper cross-origin requires explicit headers from the subresources (the <iframe> has to send headers), which is a big problem when the subresources are third-party and out of control. To mitigate this problem, there is a proposal Cross-Origin-Embedder-Policy: credentialles.

However, there's a catch: it doesn't change how <iframe> works (bummer, this is exactly what's needed!). There's a discussion about anonymous iframes, that would solve this issue, but it is not resolved yet, so I'm wouldn't hold my breath here.

So, the only option that's left is to delay this change in Chrome behavior (which can be done before Chrome 103):

  1. Request a token for your origin.
  2. Add the token to your pages. There are two ways to do that:
    • Add a <meta> tag to the head of each page. For example, this may look something like: <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • If you can configure your server, you can also add the token using an Origin-Trial HTTP header. The resulting response header should look something like: Origin-Trial: TOKEN_GOES_HERE
like image 97
Dima Parzhitsky Avatar answered Aug 17 '26 15:08

Dima Parzhitsky



Donate For Us

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!