Web server security

You can enhance web server security by deleting headers that expose sensitive information, such as Server, X-Powered-By, and version-specific headers, and by adding security-focused headers such as X-Content-Type-Options and X-XSS-Protection to mitigate common attacks.

Remove headers

By default, some of the HTTP headers might reveal information that could increase the server’s vulnerability to attacks. To reduce this risk, we strongly recommend that you disable them.

IIS 10 and above

As of IIS version 10, which comes with Windows Server 2016, you can remove the Server header by updating the web.config file.

Example:

RequestResponse
 <system.webServer> 
  <security> 
   <requestFiltering removeServerHeader="true"/> 
  </security> 
 </system.webServer> 

Older IIS versions

Older IIS versions do not support removal of the header, but you can alter the value using a rewrite rule.

Example:

RequestResponse
 <system.webServer> 
  <rewrite> 
   <outboundRules> 
    <rule name="changeServerHeader"> 
     <match serverVariable="RESPONSE_Server" pattern=".*" /> 
     <action type="Rewrite"/> 
    </rule> 
   </outboundRules> 
  </rewrite> 
 </system.webServer> 

This overwrites the Server header with an empty value.

X-Powered-By

You can also remove the X-Powered-By header in the configuration.

Example:

RequestResponse
 <system.webServer>  
   <httpProtocol allowKeepAlive="true"> 
    <customHeaders> 
     <remove name="X-Powered-By" />    
    </customHeaders> 
   </httpProtocol> 
 <system.webServer/> 

X-AspNet-Version

You can remove the X-AspNet-Version header by locating the system.web element and adding the line httpRuntime enableVersionHeader="false"/ .

Example:

RequestResponse
 <system.web> 
   <httpRuntime enableVersionHeader="false"/> 
 </system.web> 

X-AspNetMvc-Version

You can remove the X-AspNetMvc-Version by adding the following line of code in the global.asax file.

RequestResponse
MvcHandler.DisableMvcResponseHeader = true;
Note

Portal web applications omit this header by default.

X-Content-Type-Options

You can also set the X-Content-Type-Options header to nosniff. This prevents browsers from trying to "mime-sniff" or guess the content type of a response, ensuring they use the content type declared by the server.

RequestResponse
 <system.webServer> 
   <httpProtocol> 
    <customHeaders> 
     <remove name="X-Content-Type-Options"/> 
     <add name="X-Content-Type-Options" value="nosniff"/> 
    </customHeaders> 
   </httpProtocol> 
 </system.webServer> 

Add headers

We also recommend that you add several other headers to protect against common vulnerabilities like MIME-type sniffing, cross-site scripting (XSS), and clickjacking, and to make sure cookies are handled securely.

X-Frame-Options

Set the X-Frame-Options header to prevent other websites including Content Hub in a frame.

The possible values are:

We recommend you use DENY, unless you need to enable Content Hub to be used as a frame for a specific implementation. For example:

RequestResponse
 <httpProtocol> 
  <customHeaders> 
   <add name="X-Frame-Options" value="DENY" /> 
  </customHeaders> 
 </httpProtocol> 

X-XSS-Protection

Use the X-XSS-Protection header as an additional protection layer against XSS attacks.

The possible values are:

  • 0 - disables XSS filtering.

  • 1 - enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page by removing the unsafe parts.

  • 1; mode=block - enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.

  • 1; mode=report - enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the CSP report-uri directive to send a report (Chromium only).

    For example:

RequestResponse
 <httpProtocol> 
  <customHeaders> 
   <add name="X-XSS-Protection" value="1; mode=block" /> 
  </customHeaders> 
 </httpProtocol> 
Note

Mozilla provides more information about X-XSS-Protection on their website.

Secure cookies

To protect cookies from being stolen by third parties, add the Secure and HTTPOnly flags. The Secure flag ensures cookies are only sent over HTTPS connections, while the HTTPOnly flag prevents JavaScript from accessing the cookie, adding an extra layer of protection against XSS attacks.

For example:

RequestResponse
 <system.web> 
   <httpCookies httpOnlyCookies="true" requireSSL="true" /> 
 </system.web> 

Do you have some feedback for us?

If you have suggestions for improving this article,