ASP.Net Kernel: Weird X-Frame-Options Behavior

Question

I need to remove the X-Frame-Options: SAMEORIGIN from some of my actions that should display content for the iframe. While it is being added to the default queries, I disabled it in Startup.cs : services.AddAntiforgery(o => o.SuppressXFrameOptionsHeader = false); . Then I wrote simple intermediate information:

  app.Use(async (context, next) => { context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN"); await next(); }); 

The actions required to respond to cross-domain requests are decorated with a result filter attribute:

  public class SuppresXFrameOptionFilter : ResultFilterAttribute { public override async Task OnResultExecutionAsync(ResultExecutingContext context, ResultExecutionDelegate next) { context.HttpContext.Response.Headers.Remove("X-Frame-Options"); await next(); } } 

Here comes insight. The first cross-domain request fails because, despite the filter working, it is expected at the end of X-Frame-Options: SAMEORIGIN is still present in the response (I checked it after next() in the middleware - again a heading appeared). If I press F5, the title will no longer respond, and everything will work as it should. This only happens with the X-Frame-Options header, the user is deleted correctly. What does the deleted X-Frame-Options in response again?

Answer 1

I would say that on the first request Antiforgery saves a cookie, which means that it is also trying to set the X-Frame-Options header.

If you want to disable this header in Antiforgery and manually process it yourself, then you need to set SuppressXFrameOptionsHeader as true ;)

 services.AddAntiforgery(o => o.SuppressXFrameOptionsHeader = true);