Web Connection
IIS iFrame error in Edge
Gravatar is a globally recognized avatar based on your email address. IIS iFrame error in Edge
  Jay van Santen
  All
  Jun 30, 2022 @ 08:46am

Have read previous discussions discouraging the use of iFrames.

But, our application is run within the web environment of a major hospital group which deploys the Web Connection website through an iFrame.

IE 11 ran fine, but, when we use EDGE, the browser is throwing an error: "Blocked a frame with origin xxx from accessing a cross-origin frame."

I've modified the web.config file to include the following, which I understand should allow for communication between the iFrame-hosting corporate website and the website code:

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <!-- Remove the default X-Frame-Options header -->
        <remove name="X-Frame-Options" />
        <!-- Add CSP header with frame and default sources allowing HTTP and HTTPS, and inline scripts -->
        <add name="Content-Security-Policy" value="frame-src https: http; default-src https: http: 'unsafe-inline' 'unsafe-eval'" />
        <!-- Set a CORS header to allow requests from anywhere -->
        <add name="Access-Control-Allow-Origin" value="*.iFramed_Website.org" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

I'm not that familiar with IIS' web.config syntax for iFrame issues, and if anyone has any thoughts, I'd appreciate them.

Gravatar is a globally recognized avatar based on your email address. re: IIS iFrame error in Edge
  Rick Strahl
  Jay van Santen
  Jun 30, 2022 @ 10:48am

The CORS header adjustment needs to include the scheme (http:// or https://)...

Pretty sure the Content-Security-Policy has to be provided with an explicit URL (or at minimum a full base domain url).

Content Security Policy Header

All that said, I'm going to tell you that this is likely to stop working at some point as running externally hosted frames is considered an extreme security risk in the browser as the frame can potentially access the host. I realize there's no intent on your site, but it can be exploited and that's why it's been made fairly difficult to allow for frames to work by default.

For those lurking BTW - those headers that Jay is referrring to are also a good idea to explicitly add to your site for preventing your site from getting loaded into an iframe. I've had several security spam services try to exploit this and try to convince you into paying for some obscure security service 😄. The threat is real, but the solution is simple by adding X-Frame and Content Security headers that explicitly prevent IFrames from loading your content at minimum outside of your base site.

+++ Rick ---

© 1996-2024