Modern Browser support various optional Header Options which allow protection against potential attack scenarios on an web application, like frame sniffing or cross site scripting (XSS).
Please note that these header activate protection mechanisms in the browser and therefore need to be support by such. The level of support for these headers vary and can change rather quickly. Last example is the option for certificate pinning in Google Chrome RIP HPKP: Google abandons public key pinning • The Register
Also this article does not claim to be complete or show all possible security headers.
For more details on Security headers please visit OWASP Secure Headers Project
The implementation of these headers is the responsibility of the customer to be tested and verified to work in their environment and customisation of Service Desk. In case of problems please disable the headers and test again before opening a case with Ivanti Support.
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. See X-Frame-Options - HTTP | MDN for further details.
The most used directive for X-Frame-Option would be
as this tells the browser only to load content from the same web server in an Iframe. However there is some leverage to browser to apply this on top level or not.
The most common used directive for X-XSS-Protection would be
X-XSS-Protection: 1; mode=block
The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing. See X-Content-Type-Options - HTTP | MDN for further details.
The most common used directive for X-Content-Type-Options would be
Content Security Policy
On the downside it also can cause applications to stop working as expected should necessary content be blocked by the CSP. See Content Security Policy | Web Fundamentals | Google Developers for further details.
Configuration of Optional Headers in IIS
1) Open IIS Manager and select the level you wish the optional Headers for.
Note: When you define the Headers on the Server Level all Headers will apply for all websites and Applications.
2) In the IIS group open HTTP Response Headers
3) Click on Add
4) In the Name Field add the Name of the header (e.g. X-XSS-Protection)
5) in the Value Field add the directive (e.g. 1; mode=block)
6) OK the setting
7) add additional Headers or Restart IIS to test results.