Hi together,
for me works the site setting:
name: HTTP/Content-Security-Policy
content: default-src 'self' *.bing.com 'unsafe-inline'; style-src 'unsafe-inline'
--> be careful with the default-src because it can prevent inline style and inline javascript as well - could lead to non funtional portal navigation - allow unsafe-inline as well !important
(well, replace bing.com with whatever you need 🙂 ) This sets the content-security-policy header for the page which is for example respected in chrome. (do not forget cache resfresh) ( https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP )
The x-frame options is not what you want as it only allows to be ambedded in other domains (as far as i know, but not sure: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options ) whereas the content securety policy allows you to define both directions.
Nevertheless i would highly recommend not to use access to contentwindows. Use the approach which is proposed as a "workaround" in the link provided by @OliverRodrigues and use window.postMessage and a registered messagereceiver in the other windows. This is by far more safe and the recommended way to do it.
But i know: sometimes you don't have the embedded page under control...
Adam Pfau posted a list of the available settable http headers here: https://community.dynamics.com/365/b/dynamics365portalssupport/posts/http-response-headers-for-dynamics-365-portals
Hope this helps,
Christian