HTTP Security Headers (X-Frame-Options; X-XSS-Protection; X-Content-Type-Options)

Version 3

    Verified Product Versions

    Service Desk 7.6Service Desk 7.7.xService Desk 7.8.xService Desk 2016.xAsset Manager 2016.xAsset Manager 2017.xService Desk 2017.x




    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.



    Certificate Transparency (CT) is an experimental Internet security standard and open source framework for monitoring and auditing digital certificates. The standard creates a system of public logs that seek to eventually record all certificates issued by publicly trusted certificate authorities, allowing efficient identification of mistakenly or maliciously issued certificates. CT is meant to fill the gap left by lack in support of HTTP Public Key Pinning (HPKP).


    The Expect-CT header allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements, which prevents the use of misissued certificates for that site from going unnoticed. When a site enables the Expect-CT header, they are requesting that the browser check that any certificate for that site appears in public CT logs. See Expect-CT - HTTP | MDN and Certificate Transparency - Wikipedia for further details.


    Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report"




    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

    X-Frame-Options: SAMEORIGIN

    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 HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'), they can still provide protections for users of older web browsers that don't yet support CSP. See X-XSS-Protection - HTTP | MDN  for further details.


    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

    X-Content-Type-Options: nosniff

    HTTP Strict Transport Security

    The HTTP Strict-Transport-Security response header (often abbreviated as HSTS)  lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP. See Strict-Transport-Security - HTTP | MDN  for further details.

    Strict-Transport-Security: max-age=15552001; includeSubDomains; preload; redirectHttpToHttps=true


    Content Security Policy

    Content Security Policy (CSP) requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

    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.