iFrame and Cross-Origin-Embedder-Policy does not seem to work

[Yaron Shani]

Hi!
I am developing an extension that puts an iFrame inside some pages. The iFrame is being loaded from my Domain. I am doing this kind of solution 

https://stackoverflow.com/a/45370418/804533

Where I load an iframe.html from the extension which loads 
<iframe src="https://my-url.com" />  
Which works great for 90% of cases. 

Some websites uses Cross-Origin-Embedder-Policy with require-corp which forces me to use this header in "my-url.com". The issue is that "my-url.com" works with URLs other than "my-url.com" e.g accessing API or AWS S3 for example, which breaks. Not using the headers, break my extension as the iFrame is blocked. 

It seems like a but isn't it? Other security policies like CSP are not affecting the iFrame, while  Cross-Origin-Embedder-Policy does. 

This discusses the content-script issue https://groups.google.com/a/chromium.org/g/chromium-extensions/c/TWeK7YP8BQo/m/v7hjg1_wCAAJ which does not seems to be related to my question.

Any idea? is this a bug that should be reported?
Thanks!

[PhistucK]

I am not completely familiar with the way it works, but maybe using a Chrome extension sandboxed page as an iFrame and within it, embedding an https://my-url.com iFrame, would work?

On the surface, it does not seem like a bug to me, because you inject an external, remotely controlled, iFrame into the DOM of the page, so it is bound by the same restrictions others are.

There might be exceptions for Chrome extension URLs, though, so maybe try what I suggested above.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/f57a7a28-1fc1-42ab-94ab-4ca0205bf620n%40chromium.org.

[Juraj M.]

You need to inject iframe with your extension page inside which you will display the remote iframe.

Like this:

html > body > AWS page... > iframe src="chrome-extension://..." > html > body > iframe src="https://your_domain"

Like in Inception :D

[Juraj M.]

OMG, did I just repeated what @PhistucK already said above? I need to focus more, I'm sorry.

But yeah, extension iframe is allowed on every page and your extension page doesn't have CSP to prevent remote iframes so it will work 100%.

[Yaron Shani]

Thanks for the info!
As you can see from the picture, I am actually using this technique of iFrame inside chrome extension iFrame

This works for almost all cases, including CSP like frame-src, but it does not work for Cross-Origin-Embedder-Policy header like https://steamdb.info . Can you please confirm your technique works for that website?
Regarding sandbox pages, its seems loading iFrame from remote url is forbidden in sandbox pages. From google docs (https://developer.chrome.com/docs/extensions/mv2/manifest/sandbox/):

"Also, the CSP you specify may not allow loading external web content inside sandboxed pages."

So I dont see how it will solve the issue :(
Any info would be really appreciated. Thanks!

[Juraj M.]

Oh man, you are right, it indeed doesn't work in Chrome! :(

It works in Firefox though, so maybe it would be worth report it as bug.

But I wonder, was it always broken? Or did it break in MV3? I can't believe nobody reported it to me yet because one of my extensions is affected by this bug now :(

[Yaron Shani]

This header is relatively new, this is probably why this is why we are porbably seeing it only now.
This isnt realted to MV3, it happens also in MV2. 
This is why I am thinking this is a bug.
Yeah.. I am on the same boat.. having broken extension :(

Thanks!

[Juraj M.]

Yeah, so this is pretty bad.

The only solution I can think of is removing the header completely from top-level requests :), like this:

```

chrome.declarativeNetRequest.updateSessionRules({
  addRules: [{
    id: 1,
    condition: {
      resourceTypes: ['main_frame'],
    },
    action: {
      type: 'modifyHeaders',
      responseHeaders: [
        {header: 'cross-origin-embedder-policy', operation: 'remove'},
      ],
    },
  }],
});

```

That's a pretty sinister solution though, so applying it only a specific host / tab would be much better.

[PhistucK]

I think the lack of this header will have some effect on functionality, shared array buffer is unsupported without it, if I am not mistaken and document.domain will cease working soon, too, I believe.

Please, report (or star if a report exists) this via crbug.com as this prevents the extension system from being effective.

☆PhistucK

[Yaron Shani]

I do agree that removing the header is probably not ideal.
Also, using the header in the remote iFrame does the job, but it limits and basically fail the iFrame in many cases where it contacts some API or cloud. 
I opened an issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=1335034