MVC 5 prevents access to content via Iframe

Question

Ever since the upgrade from MVC4 to MVC5, I have noticed an extra server header added to my web pages:

X-Frame-Options: SAMEORIGIN

I understand security benefits of adding this tag, but one of the pages is meant to be included inside an iframe from other projects (on other domains), this extra header is preventing this.

I have verified it is not the hosting IIS7 server that is adding the header, and when I downgraded back to MVC4 - the header is gone.

Does anyone know how to remove this default from MVC5?

This [same question](http://stackoverflow.com/questions/20253840/afer-update-to-mvc-5-iframe-no-longer-works) was just asked, so if you don't get an answer here, keep an eye on that one. — Joe Enos, Nov 27 '13 at 22:31

Colin Bacon · Accepted Answer · 2013-12-16T16:30:12.053

104

MVC5 automatically adds the HTTP header X-Frame-Options with SAMEORIGIN. This prevents your site from being loaded into an iframe.

But we can turn this off in Application_Start in the Global.asax.cs.

Example

protected void Application_Start()
{
    AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
}

Update

I have written a post about this MVC5 prevents your website being loaded in an IFRAME

edited Dec 16 '13 at 16:30

answered Nov 28 '13 at 09:28

Colin Bacon

15,436
7
52
72

1

What if I only want to allow certain pages to be iframe loaded? Previously I had a custom attribute `AllowAnyOriginAttribute : ActionFilterAttribute`. Can I change the configuration per request, or is `Application_PreSendRequestHeaders` still preferred in this scenario (as per http://stackoverflow.com/a/20254341/65611)? – Joel Jul 21 '14 at 14:19
1

Thanks, this helper @Html.AntiForgeryToken() is what causes the header to be added. In AntiForgeryWorker.cs: `if (!this._config.SuppressXFrameOptionsHeader) httpContext.Response.AddHeader("X-Frame-Options", "SAMEORIGIN");` – Jared Kells Sep 28 '14 at 02:56
You could just add this to your `web.config` ` ... ... ` – Harry89pl May 08 '15 at 11:07
5

This answer requires the System.Web.Helpers namespace in your global.asax file. – Jim Yarbro Sep 20 '15 at 12:32
Http Headers issues: https://stackoverflow.com/questions/34270192/server-cannot-append-header-after-http-headers-have-been-sent-exception-at-html?noredirect=1&lq=1 – Kiquenet Mar 18 '19 at 14:23

score 4 · Answer 2 · edited May 23 '17 at 12:26

4

Try something like this in Global.asax:

protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
 {
   HttpContext.Current.Response.Headers.Remove("X-Frame-Options");
 }

EDIT:

Look at answer of Colin Bacon. It is more correct than mine.

In short - don't remove this header if you don't want to run your site in IFRAME because it will open forgery vulnerability. But if you still want to remove it - use AntiForgeryConfig.SuppressXFrameOptionsHeader = true; in Application_Start, it is more cleaner way for doing this.

edited May 23 '17 at 12:26

Community

1
1

answered Nov 27 '13 at 22:31

Oleksii Aza

5,368
28
35

It feels a bit like a hack, right before the page is sent out, the tag is stripped, but it works, so I am accepting your answer. - It would be nice to know why the tag is being added though. – Leszek R. Nov 27 '13 at 22:47
2

We can actually suppress this in app_start with `AntiForgeryConfig.SuppressXFrameOptionsHeader = true;` – Colin Bacon Nov 28 '13 at 09:30
Nice. Easy fix for a not so good code with 300 form tags with antiforgeries on each one. – Dmitri Trofimov Apr 27 '16 at 12:23
Isn't this the better answer if you only want to allow some pages to be accessed via an IFrame? – StuartQ Jul 19 '16 at 09:30

score 3 · Answer 3 · answered Jun 30 '16 at 18:47

If you want a little more flexibility, here's an ActionAttribute that adds/removes headers based on a whitelist. If the referrer isn't in the whitelist, then the SAMEORIGIN header is left in place. I was going to paste the code, but SO complains about the length.

https://long2know.com/2016/06/asp-net-anti-forgery-xframe-options/

score 3 · Answer 4 · answered Mar 27 '19 at 05:18

Personally, I don't think it's a good idea to disable the X-Frame-Options across the whole site.I've created an ASP.NET MVC filter which removes this header and I simply apply this filter to the portions of the site that are used in iFrames e.g. widgets.

public class AllowDifferentOrigin : ActionFilterAttribute, IActionFilter
{
    public override void OnResultExecuted(ResultExecutedContext filterContext)
    {
        filterContext.HttpContext.Response.Headers.Remove("X-Frame-Options");
        base.OnResultExecuted(filterContext);
    }
}

score 2 · Answer 5 · answered Aug 27 '15 at 14:36

Here is a replacement Extension method for the HtmlHelper class. It will first clear all X-Frame-Options headers and then add back a single X-Frame-Options header normally added by the built-in AntiForgeryToken method.

This technique respects the SuppressXFrameOptionsHeader setting, but has the downside of removing all previously added X-Frame-Options headers, even those with values other than SAMEORIGIN.

public static MvcHtmlString AntiForgeryTokenSingleHeader(this HtmlHelper html)
{
    string token = AntiForgery.GetHtml().ToString();
    HttpResponseBase httpResponse = html.ViewContext.HttpContext.Response;

    httpResponse.Headers.Remove("X-Frame-Options");
    if (!AntiForgeryConfig.SuppressXFrameOptionsHeader)
    {
        httpResponse.AddHeader("X-Frame-Options", "SAMEORIGIN");
    }
    return new MvcHtmlString(token);
}

MVC 5 prevents access to content via Iframe

5 Answers5

Linked