Securing CXO

This page describes a number of configuration options to adjust the security of your CXO application. Basic knowledge of .NET configuration files is required to apply these options.

HTTP Strict Transport Security (HSTS)

Configuring HSTS ensures that all traffic with the server is done using secure HTTPS connections, when SSL/TLS is correctly configured for CXO-Cockpit. HSTS can be configured in the Web.config of CXO-Cockpit via the Configurator by adding the Strict-Transport-Security header to the customHeaders element in the system.webServer section.

<configuration>
        :
  <system.webserver>
        :
    <httpProtocol>
      <customHeaders>
        : 
        <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains"/>
        :
      </customHeaders>
    </httpProtocol>
        :
  </system.webserver>
        :
</configuration>

Secure Cookies

When using HTTPS protocol for the CXO website, it is advised to set the following flags on cookies:

• Secure. Enabling the Secure flag ensures that cookies are not sent over unsecure HTTP connections. This mitigates information leakage.
• SameSite. Enabling the SameSite flag ensure that cookies are only sent with request done from the same domain. With requests done by other websites, the cookies are not sent. This mitigates information leakage and risks of CSRF.

To add these flags to the cookies used by the CXO-Cockpit application, the Web.config file should be changed. This can be done through the Configurator.

Enable Secure flag

To enable the Secure flag on cookies set the attribute requireSSL on the httpCookies element in the system.web section.

<configuration>       
        :
  <system.web>
        :
    <httpCookies ... requireSSL="true" />
        :
  </system.web>
        : 
</configuration> 

Enable SameSite flag

To enable the SameSite flag on cookies the Web.config needs to be extended with a rewrite rule. To be able to use rewriting within IIS, the URL Rewrite component needs to be installed. More information can be found here: IIS Rewrite module.

After this component is installed, add the following configuration to the system.webServer section.

<configuration>
       :
  <system.webServer>
       :
   <rewrite>
     <outboundRules>
       <rule name="Add SameSite" preCondition="No SameSite">
         <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
         <action type="Rewrite" value="{R:0}; SameSite=strict" />
       </rule>
       <preConditions>
         <preCondition name="No SameSite">
           <add input="{RESPONSE_Set_Cookie}" pattern="." />
           <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=strict" negate="true" />
         </preCondition>
       </preConditions>
     </outboundRules>
   </rewrite>
 </system.webServer>
       :
</configuration>

Cross-Origin Resource Sharing (CORS)

From version 21.1.1, by default Cross-Origin Resource Sharing (CORS) settings are disabled, because CXO does not require CORS as the website and its APIs are hosted on the same server.

If you would like to have CORS on CXO, adjust the following settings

• Set "Cross-Origin Resource Sharing (CORS): Enabled" to true. Default value is false.
• Set "Cross-Origin Resource Sharing (CORS): Allowed origins" to a comma separated list of allowed origins (e.g. http://example1.com,  https://example2.com). Default value is an empty string (no origins allowed).
  • More info:
    • The list of allowed origins should be as strict as possible.
    • To allow multiple sub origins you can use "*" sign in the name e.g. (e.g. "https://*.example.com", "https://localhost*")
    • It is possible to allow any origin by specifying "*" string it he "Allowed origins" field. This setting is strongly discouraged since it is insecure configuration. We advise to use it only for in experimentation phase.

With CORS enabled, if you want to allow also sending credentials with a cross-origin requests, adjust the following settings

•  Set "Cross-Origin Resource Sharing (CORS): Allow Credentials" to true. Default value is false.
  • More info:
    • Please be aware that allowing cross-origin credentials is a security risk. A website at another domain can send a signed-in user's credentials to the app on the user's behalf without the user's knowledge.
    • The CORS specification also states that setting allowed origins to "*" (all origins) is invalid if the Access-Control-Allow-Credentials header is present.
    • In case credentials are allowed for CORS, please make sure that "Cross-Origin Resource Sharing (CORS): Allowed origins" is not set "*" otherwise some browsers might refuse the requests.

Content Security Policy (CSP) Header

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

CSP (Content Security Policy) header can be configured in the Web.config of CXO-Cockpit via the Configurator if it is required for a security reason by our customers.

Initial setup we provide is the following:

  
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        ....
        <add name="Content-Security-Policy" value="default-src 'self' https://app.powerbi.com 'unsafe-inline'; img-src 'self' https: blob: data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'" />
      </customHeaders>
    </httpProtocol>
    ... 
  <system.webServer>

We provide WebView control that can be used to load external website that allow embedding.

With adding the CSP header website that are configured in our WebView control will need to be added in the above web.config configuration. For example if the website that we want to add in WebView control is https://embedded.website.example.com CSP configuration in the web.config will look as following:

  <system.webServer>
    <httpProtocol>
      <customHeaders>
        ....
        <add name="Content-Security-Policy" value="default-src 'self' https://app.powerbi.com https://embedded.website.example.com 'unsafe-inline'; img-src 'self' https: blob: data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'" />
      </customHeaders>
    </httpProtocol>
    ...
  <system.webServer>