HTTP security headers provide an extra layer of security to web applications. They help mitigate attacks and protect against security vulnerabilities. When a user visits a site through their browser, the server responds with HTTP response headers. These headers tells the browser how to handle the returned content based on the configured settings.

This document covers how to add HTTP security headers to web pages to enhance security of the SecureAuth® Identity Platform (formerly SecureAuth IdP) appliance.

Note about HTTP security headers:

The baseline recommendations are intentionally permissive to account for multiple product versions and customer enhancements. As a system administrator, you can increase the level of security for each header specific to the Identity Platform. Be sure to validate any changes to the baseline settings or increase in restrictions in a test environment. Improper implementation of HTTP security headers can cause undesirable behavior in the Identity Platform environment.

Add a response header

To implement a HTTP security header, add the header as an HTTP response header in Internet Information Services (IIS)

  1. Open the Internet Information Services (IIS) Manager

  2. From Connections pane, locate and click Default Web Site
  3. Double-click HTTP Response Headers
  4. In the Actions pane, click the Add link.
  5. In the Add Custom HTTP Response Header dialog, enter the Name and Value for the HTTP security header type to be used.
    Select a security header topic for configuration options. 

Content Security Policy (CSP)

The Content Security Policy (CSP) header protects against cross-site scripting (XSS) security vulnerabilities. For the Identity Platform, use a whitelist of approved content sources added in the header of the web page. In a standard deployment, all content should only come from the appliance itself.

For more information about CSP, see the document by security researcher Scott Helme, Content Security Policy - An Introduction


Content-Security-Policy: default-src 'self' data: 'unsafe-inline' 'unsafe-eval';

Cross Site Scripting Protection (X-XSS)

The X-XSS-Protection header protects against Cross-Site Scripting attacks. It works with the built-in reflective XSS protection in Internet Explorer, Chrome, and Safari browsers.

For more information about the X-XSS-Protection header, see the document by OWASP, OWASP Secure Headers Project


X-Xss-Protection: 1; mode=block

HTTP Strict Transport Security (HSTS)

The HTTP Strict Transport (HSTS) header forces the web browser to communicate over secure HTTPS instead of HTTP. This HSTS header helps mitigate man-in-the-middle (MitM) attacks. This forces bookmarks, links, or URL addresses to use HTTPS, even if they specify HTTP.

For more information about HSTS, see the document by security researcher Scott Helme, HSTS - The missing link in Transport Layer Security


Strict-Transport-Security: max-age=31536000 ; includeSubDomains


The X-Content-Type header protects a browser from content sniffing (MIME) attacks. The header specifies what MIME types to follow in the browser to reduce exposure to drive-by downloads.

For more information about the X-Content-Type header, see the Mozilla Developer Network document, HTTP Headers: X-Content-Type-Options


X-Content-Type-Options: nosniff


The X-Frame-Options (XFO) header prevents clickjacking attacks by not allowing iframes to load on a web page.

For more information about the XFO header, see the document by security researcher Troy Hunt, Clickjack attack – the hidden threat right in front of you


X-Frame-Options: SAMEORIGIN

  • No labels