HTTP Security Headers

• Access-Control-Allow-Origin Value =”*” Already set in application. Added to handle Cross-Origin Resource Sharing.

• The Access-Control-Allow-Origin response header indicates whether the response can be shared by requesting the code from the given origin.

  • * - to access from all sites.

    or

  • https://abc.com - to access from specified server

• Access-Control-Allow-Headers Value=”Content-Type, Accept, From, Authorization, IPAddress” Administrators can set the values as required. These are values set in application config.

• The Access-Control-Allow-Headers response header is used in response to a preflight request which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request.

• Access-Control-Allow-Methods Values=”POST, PUT, GET, DELETE”. Administrators can set the value as required. These are values set in application config.

• The Access-Control-Allow-Methods header indicates which HTTP methods are allowed on a particular endpoint for cross-origin requests. If you allow all HTTP methods, set the value to something like Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD. However, if you want to limit the endpoint to only a few methods, you should only include those methods.

Clickjacking (classified as a User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages.

• X-Frame-Options—This is already handled at the application level.

  This is used to restrict loading the application into iframe.

  Default is set to sameorigin.

• Content-Security-Policy—This is already handled at the application level and supported. We block default content Source and allow only the necessary content sources (default-src 'none').

Add the following configuration to the web.config file of Console.

<remove name="content-security-policy" />

<add name="content-security-policy" value="default-src 'none';

script-src 'self' 'unsafe-inline' 'unsafe-eval';

style-src 'self' 'unsafe-inline';

img-src 'self' 'unsafe-inline' data:;

font-src 'self';

connect-src 'self'[WSS URL];

form-action 'self';

frame-ancestors 'self' ;

frame-src 'self'" />

Note:

If the application operates on HTTPS and does not load images, include "https" after "data" in the above configurations. Example: img-src 'self' data: https:;

Configure the WSS URL here to access Performance Metrics. Also, update the URL change here.

Configure the following properties:

frame-ancestors 'self' defines that the Console application must not be loaded in an iframe other than Console-hosted domain. If the Console has to be loaded in iframe of another domain (for example, test.otherdomain.com), change the frame-ancestors to 'self' test.otherdomain.com.

frame-src 'self' defines that the Console must not load any sites in iframe other than the Console-hosted domain. If the Console has to load sites of other domains (for example, test.otherdomain.com) in the iframe, change the then we need to change the frame-src to frame-src 'self' test.otherdomain.com.

The HTTP Content-Security-Policy response header allows web site administrators to control resources the user Agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS).

As a best practice, use the frame-ancestors as part of the HTTP Content-Security-Policy, if defined. Avoid using the X-Frame-Options header.

• The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps to guard against cross-site scripting attacks (XSS).

• Strict-Transport-Security—Supported. You must add into IIS server.

  • If a website accepts HTTP requests and redirects to HTTPS, the system is vulnerable till the redirection is successful. To prevent this, the following measure is taken:

    value= "max-age=31536000” is set to accept https request only with the configured time (optional). The time, in seconds, is set for 365 days (converted into seconds). This ensures the browser does not load the application in HTTP for the configured time. Since the time is large, no intruder can gain access to the application in the interim period of transition from HTTP to HTTPS.

• Cache-Control—This general header field is used to specify directives for caching mechanisms in both requests and responses. The application already adds this as part of the response header. Among the various configurations that may be applied, our application uses value= ”no-cache, no-store, must-revalidate”.

  • no-cache—Forces caches to submit the request to the origin server for validation before releasing a cached copy.

  • no-store—The cache should not store anything about the client request or server response.

  • must-revalidate—The cache must verify the status of the stale resources before using it and expired ones should not be used.

• X-Content-Type-Options—Supported. This is already handled at the application level.

• X-XSS-Protection value = “1; mode=block”—Supported. This is already handled at the application level.

  • 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.

• Content-Security-Policy—Not supported as of now. This should be removed from IIS default web site.

  • The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS).

• Referrer-Policy value=”no-referrer”—Supported. This is already handled at the application level.

  • Referrer-Policy is a security header designed to prevent cross-domain referrer leakage. Referrer header is a request header that indicates the site, which the traffic originated from.