Need help with X-Frame-Options response header configuration - IIS8

ADJ-admin used Ask the Experts™
I am trying to fix a vulnerability found during a penetration scan. I need to correct the  X-Frame-Options response header and set it to DENY so that the webpage is unable to be opened in a frame. I found this page:

That says to add this to the <system.webServer> section.


      <add name="X-Frame-Options" value="SAMEORIGIN" />


to my web.config file. It looked straightforward enough, so I found that section and added that to the web.config file and still getting the alert when I run the penetration test after the change was made.

I need to know if there is something else I need to do in order for this to be set correctly.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®


see above


I also found this and the header is currently set to DENY, please advise:

The X-Frame-Options header can be used to control whether a page can be placed in an IFRAME. Because the Framesniffing technique relies on being able to place the victim site in an IFRAME, a web application can protect itself by sending an appropriate X-Frame-Options header.

To configure IIS to add an X-Frame-Options header to all responses for a given site, follow these steps:

    Open Internet Information Services (IIS) Manager.
    In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
    Double-click the HTTP Response Headers icon in the feature list in the middle.
    In the Actions pane on the right side, click Add.
    In the dialog box that appears, type X-Frame-Options in the Name field and type SAMEORIGIN in the Value field.
    Click OK to save your changes.
In my experience, this section needs to be added in the applicationhost.config file rather than the web.config. This is also a better approach because web.config changes can be overwritten easily as new versions of applications are deployed unless good source control practises are in place.

You can follow the instructions above using the GUI tool or you can run the following PowerShell script on the server (as Administrator).

$Header = 'X-Frame-Options'

Add-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter 'system.webServer/httpProtocol/customHeaders' -name '.' -value @{name=$Header;value=$Value}

Open in new window

Become a CompTIA Certified Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.


I checked the values in the GUI following the instructions and it shows the value set to DENY. Not sure if this is working as the test I run (OWASP ZAP) is still showing that this is not set correctly. Would running the above script produce a different result?
You have to remember that IIS configuration is hierarchical and it can be sometimes difficult to work out which settings have been applied.

Roughly speaking it goes like this:

machine.config -> root web.config -> applicationhost.config -> web.config

The GUI tool will always choose to write configuration into the most specific location it can (normally the web.config but sometimes the applicationhost.config if that section is "locked"). You can see this in the window status bar (bottom left hand side) when you are in features view.

It will be either:
Configuration: 'web site name' web.config
Configuration: 'localhost' applicationhost.config
Configuration: 'localhost' applicationhost.config <location path = 'web site name'>

If you remove an entry that has been applied at a server level then IIS will write a remove in the web.config which is represented by the setting not showing in the GUI. In this case running the script above would not help because more specific settings take precedence.

It might well be that you have a setting in the web.config to remove the header. You will need to check the appropriate section in your web.config file to see whether this is the case.

If there is nothing in the system.webServer/httpProtocol/customHeaders section in either the applicationhost.config file or the web.config then the script above will add the header correctly.

Hope that makes sense.



The above information helped me achieve the desired response, that is, the form will not allow a frame to be called for the page(s) in question. My issue now is that OWASP still flags this as it is not working and I am trying to figure out why this is happening.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial