HTTP security headers

Introduction

Safewhere Identify now has support for a set of HTTP response security headers that per OWASP: "your application can use to increase the security of your application. Once set, these HTTP response headers can restrict modern browsers from running into easily preventable vulnerabilities."

It is important to state that turning on all HTTP security headers is not always the solution. OWASP also states that "HTTP headers are well known and also despised. Seeking the balance between usability and security developers implement functionality through the headers that can make your more versatile or secure application."

This document will list all recommended headers that are in used by Identify, what are they, their impacts and how to resolve some issues.

Implementation

Recommended security headers are stored as a JSON file in Identify Configurator.

http-security-headers-ic-json

When installing a new Identify tenant or upgrade an existing Identify tenant, Identify Configurator has a new Security setup step that allows you to either apply all those security headers or none of them.

http-security-headers

If you choose to apply all those headers, a Web.config file will be created at the root folder of the installed tenant directory.

http-security-headers-webconfig

In addition, if a Web.config file already exists in that folder, Configurator will create a back up for it whose name is Web.config.backup so that you can manually revert to the previous version easily.

What those headers do

  1. Strict-Transport-Security header is used to let browser know the site should be used with HTTPS only. This header only take effect when the HTTPS certificate is valid (green status on address bar of browser).
  2. X-Permitted-Cross-Domain-Policies grants or forbid web client such as Adobe Flash Player or Acrobat permission to handle data across domains.
  3. Cache-Control is browser caching policy. By default, we disable browser caching for Identify Admin and Identify Runtime. However, we enable browser caching for Safewhere Admin (aka Adminv2). The reason is that Safewhere Admin has a lot of JavaScript, CSS resources that are bundled in a unique file name (GUID) per every build and enabling Cache-Control can improve loading time significantly.

http-security-headers-cache-control

  1. X-Frame-Options restricts injecting iframe whose src is from another domain. Setting this header may affect NemID iframe or any setup in which Identify is embedded inside an iframe of customer’s application. This header and Content-Security-Policy have the same usage. Please refer to Content-Security-Policy for more detail.
  2. Content-Security-Policy is a group of policies to restrict content from external domains. Pattern of value of this header is: "name-of-policy-a: ‘self’ domain1 domain2; name-of-policy-b: ‘self’ domain1 domain2", where domain1 and domain2 are allowed domains. After enabling recommended security headers on Identify, we recommend that you turn on your browser’s developer tool to check it reports any issue when you are accessing Identify pages. If an external domain is restricted by this policy, there will be an error on console log. After you have found what external sources you need to allow, you can add exception for them as we did for NemId whose path is /nemid/authentication.idp.

http-security-headers-content-policy

Another example is the exception we added for Inline Manual tool and Gravatar in Safewhere Admin:

http-security-headers-content-policy-example

  1. X-XSS-Protection is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.
  2. X-Content-Type-Options is related to Content-Type validation on browser. In Identify, this setting prevents captcha.ashx from displaying correctly so we had to add an exception for it as follow:

http-security-headers-content-type

  1. Feature-Policy provides a mechanism to allow or deny the use of browser features in its own frame, and in iframes that it embeds.

Troubleshooting

After you enable all HTTP security headers and something doesn’t work as expected, we recommend that you have a look at your browser’s developer tool. Its console log probably tells you what the error is and a quick search on the internet will help you fix it.