Predefined security headers in HTTP response

This HTTP header controls the resources that the user agent is allowed to load. It specifies the server origins and script endpoints for page resources. It also very useful for protection against XSS. 

IMPORTANT: Misconfiguration may block some resources from loading. 
If the header is turned on with the default, preconfigured value, it blocks almost each external resource from loading and this may prevent pages to use external CSS, fonts, images, scripts, etc. If your site is using external resources, you should allow all trusted domains in the header configuration for each respective resource type.

NOTE: You can use the Content-Security-Policy-Report-Only header that will allow you to fine-tune the header without breaking any existing pages. For more information, see Administration: Configure reporting.

For more information about using the Content-Security-Policy header, see:

• http://content-security-policy.com/
  
• http://www.w3.org/TR/CSP3/
  

This HTTP header tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates. 

This header is disabled by default, because it requires configuration of the public key of the certificate that is used for transport layer encryption.

NOTE: You can use the Public-Key-Pins-Report-Only header that will allow you to fine-tune the header without breaking any existing pages. For more information, see Administration: Configure reporting.

For more information, see http://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning.

This HTTP header governs which referrer information, sent in the Referrer header, should be included with requests made. 

For more information, see http://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy. 

This HTTP header prevents sending data over unencrypted channel when a secured one is available. Strict - Transport - Security - HSTS tells browsers that content should only be communicated using HTTPS, instead of HTTP. It converts automatically all HTTP requests to HTTPS, if the site has been opened previously under HTTPS with valid certificate. 

For more information, see http://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet. 

This HTTP header prevents content sniffing for styles and scripts. 

For more information, see http://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options. 

This HTTP header indicates whether or not a browser should be allowed to render a page in a <frame>, <iframe>, or <object>. It helps protecting against clickjacking attacks. 

For more information, see http://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet.

This HTTP header prevents reflected cross-site scripting attacks. Default value blocks the rendering of a page if an attack is detected.

NOTE: Value 1, entered in the field before the response URI, means the all attacks will be blocked and reported to the configured URI.

For more information, see http://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection. 

For more information, see Administration: Configure reporting.

In addition to the out-of-the-box preconfigured headers that Sitefinity CMS comes with, you can create your own additional headers.

To do this, navigate to Administration » Settings » Advanced » WebSecurity » HttpSecurityHeaders » ResponseHeaders » Create new.

HTTP protocol and browsers evolve. So, the list of headers should be extended and configurations should be kept up to date.