CODEWITHSUNDEEP
asp.net-mvcasp.net-mvc-5antiforgerytokenx-frame-options
ManxJason
ManxJason

Reputation: 940

Suppressing anti-forgery X-Frame options header in the global.asax weakens security despite setting X-Frame options in Web.config?

Our MVC5 application contains a partial view that renders a Html.AntiForgeryToken on all pages using the Master.cshtml.

On pages where we render another form, and another Html.AntiForgeryToken, on form submission an exception is thrown:

Server cannot append header after HTTP headers have been sent.

To avoid the exception, within the Global.asax App_Start we can specify:

AntiForgeryConfig.SuppressXFrameOptionsHeader = true;

Our concern here is we're enabling others to embed our website as an iFrame, and enabling 'ClickJacking'?

The above mentioned occurs regardless of us also using Umbraco 7.6.1 which requires we specify within our Web.config:

    <httpProtocol>
     <customHeaders>
      <remove name="X-Powered-By" />
      <add name="X-Frame-Options" value="SAMEORIGIN" />
     </customHeaders>
    </httpProtocol>

Is there an alternative to this contradictive configuration? Are we weakening security?

Upvotes: 3

Views: 3128

Answers (1)

Winston King
Winston King

Reputation: 66

By suppressing the X-Frame-Options header from Html.AntiForgeryToken, you potentially weaken security by assuming responsibility for applying the X-Frame-Options header.

In your case security is not weakened because you are using the Web.config to apply an X-Frame-Options header with the same value that Html.AntiForgeryToken would apply. Your security is actually stronger than what Html.AntiForgeryToken provides because the X-Frame-Options header will be applied to all responses which includes forms where you neglected to or can't use Html.AntiForgeryToken.

Upvotes: 3

Related Questions