I have created a dotnet core 3.1 application that is being hosted on Azure. I would like to be able to use an iframe and embed the app in sharepoint however I get a connection refused error when attempting to create and preview the iframe. Is this something that Azure will not allow me to do or is there a security setting in the code that needs to be added?
There are two ways to block a web site to be embedded in another site.
This is the current recomendation of W3C
E.g: Content-Security-Policy: frame-ancestors 'self' https://www.example.org;
E.g: X-Frame-Options: ALLOW-FROM allowed uri
You don't need to use both, as you can read at W3C documentation. Content-Security-Policy is the prefered one and x-frame-options will only work for very old browsers or when you do not set Content-Security-Policy.
The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored
Problably your application or your server is injecting one of the above headers to block the content to be embbed.
To allow your application to be embedded in an iframeyou should add in your response header one of this two headers, preferencialy with the specific domain that can embed it.
So first of all check if is your application that is adding the header that is blocking your content from be embedded. If you have configured AntiForgery on your application, this is probably the case. As this is done by default by Antiforgery. So you need to configure it to do not add this header setting SuppressXFrameOptionsHeader = true when configuring AntiForgery.
services.AddAntiforgery(o => o.SuppressXFrameOptionsHeader = true);
Be aware that when you disable that header in Antiforgery you should manually handle it yourself. The above code will remove the X-Frame-Options from all yours responses. So you need to write your own logic to add this header to limit the domains that are allowed to embed your web site.
If this do not resolve your problem probably is your server, CDN, or reverse-proxy that is injecting this header. So you need to analyse your infra structre to discover who is responsible for that and then do the proper configuration.