In order to show your shiny remote provider hosted app in a dialog or IFrame, the calling domain of the page with the IFrame, must match the domain of the target page (the page being IFramed).
Why might you do this? well there a quite a few patterns in the OfficeDev PnP which use remote provider hosted apps, and showing them in dialogs. Not many MVC apps to be sure, but given that WebForms (ASPX) style applications are not supported in the upcoming ASP.NET 6, MVC suddenly becomes much more attractive.
The target page server (server hosting the page being IFramed) may (or may not) include the X-Frame-Options HTTP header which is set to either;
- DENY
- SAMEORIGIN
- ALLOWFROM {a domain uri}
The browser inspect this header value and respects the value accordingly, read more about it here.
So, you create a SharePoint provider hosted app and you attempt to call it in a dialog, but you get an error in the browser console saying that the load was denied due to a cross origin framing error.
And looking at the response HTTP headers you see the X-Frame-Options header set to SAMEORIGIN
So how do we disable this?
In ASP.NET WebForm (ASPX) Apps the solution is rather easy, you just add the AllowFraming server control to the page, as described here.
<WebPartPages:AllowFraming runat="server" />
To do this in an MVC App wasn’t obvious, to me at least, and Googling didn’t seem to help much either.
However, the solution turns out to be rather easy, edit the Global.asax.cs file and add the following code;
Using the AntiForgeryConfig class, set the SupressXFrameOptionsHeader property to false.
platinumdogs.me 
Cheers for this! Helped us out a treat
Hi
I was wondering if you could help me. I have tried the above
and it did not resolve my issue. We have hosted MVC 5 app
on Azure and we want to see it through a page viewer, on our
SharePoint online site. The page only loads if I put the azure site
in trusted sites. Is there another work around.
jayakrishna/
If you’re using IE10+, then yes you’ll need to add it to the trusted sites list, just the *.azurewebsites.net is enough, which can be done using an AD group policy.
If you’re using Chrome or FireFox this isn’t neccesary
My Network Admin says this is only a work around and not a fix.
Is there a fix for this?
jayakrishna/
Well there isn’t really a bug to fix, if anything it’s just a consequence of how IE security zones work with some sites, which in some cases can cause infinite SSO/login loops amongst other things.
As I said, if you use Chrome for instance, there isn’t an issue.
The following is a list of the recomended FQDNs to add to the Trusted sites list, the Intranet list is mostly there if you’re using WebDAV features, you can add in Azure if required; *.azurewebsites.net
Trusted Sites Zone:
https://*.microsoftonline.com
https://*.sharepoint.com
https://*.outlook.com
https://*.lync.com
https://*.office.com (if using the Office store)
Intranet Zone:
*.microsoftonline.com
*.sharepoint.com
*.outlook.com
*.lync.com
*.office.com (if using the Office store)