Configuring Secure Headers

* Applies to Rhythmyx 7.3.2 Patch level 732_20180608 or greater *

* Applies to CM1 5.3 SR1 Patch level 5315_20180816 or greater *

HTTP Headers allow the server and the client to exchange additional information about an HTTP request. Percussion supports the configuration of a number of HTTP headers designed to add additional security to the application.  These headers follow best practices for modern web applications.  These headers mitigate security vulnerability CWE-693.

Cache-control header

The Cache-control header tells client web browsers how they should cache requests to Rhythmyx resources.  This header is turned on by default for all requests.

Location: <installDir>/rxconfig/Server/server.properties

Setting: requireCacheControl

Default: true

Setting: cacheControl

Default: no-cache\='Set-Cookie, Set-Cookie2',must-revalidate

The default setting for cache control tells remote browsers to turn off caching for all cookies and to revalidate cached items with the server on each client request.   See the Http Caching page on the Mozilla Development Network for more information.  It should be noted that any Http session related resources are always set to no-cache regardless of the cacheControl setting. 

X-Content-Type-Options

The X-Content-Type-Options header tells client web browsers how they should handle mime/type detection for resources returned by the application server.  This header is used to prevent a security flaw where non-executable content could be treated as executable content.  This header is on by default for all requests.

Location: <installDir>/rxconfig/Server/server.properties

Setting: requireXContentTypeOptions

Default: true

Setting: xContentTypeOptions

Default: nosniff

The default setting tells remote browsers to turn off mime type sniffing for all requests, the server will set all mime/types correctly. See the X-Content-Type-Options page on the MDN for more information on this header.  

X-Frame-Options

The X-Frame-Options header tells client web browsers how they should handle requests to the requested resource that are made in frames, iframes, or object references.  This header is used to help to prevent "click-jacking" attacks on a web application.  This header is on by default for all requests.

Location: <installDir>/rxconfig/Server/server.properties

Setting:  requireXFrameOptions

Default: true

Setting: xFrameOptions

Default: SAMEORIGIN

The default setting tells remote browsers to allow for application pages to be Framed only if the frame is also served from the SAME application server.  For more information on header options, see the X-Frame-Options page on the MDN.

X-XSS-Protection

The X-XSS-Protection header is a feature of Chrome, Internet Explorer, and Safari browsers that stops a Page from loading when the browser detects an XSS attack.  This header is turned on by default for all requests.  See the X-XSS-Protection page on the MDN for more information on this header. 

Location: <installDir>/rxconfig/Server/server.properties

Setting: requireXXSSProtection

Default: true

Setting: xXSSProtection

Default:  1; mode\=block

The default setting turns on client side XSS filtering and tells the browser to block the page if an attack is detected. 

Content Security Policy

The Content Security Policy provides a robust mechanism for securing a web application using a number of policy directives embedded in a single HTTP header.  As Percussion is a Content Management System that is used for the development and production of web sites, this header requires carefull consideration before it is turned on. As a result this header is turned off by default. 

Location: <installDir>/rxconfig/Server/server.properties

Setting: requireContentSecurityPolicy

Default: false

Setting: contentsecuritypolicy

Default:  default-src 'self' 'unsafe-inline' 'unsafe-eval'

The default content security policy provides a basic security policy that indicates that CSS and JavaScript resources may be retrieved from the Application Server but no remote sources.  It also allows inline <script> and <style> blocks within served content and allows for use of the JavaScript eval command (currently used in the Active Assembly Editor).

When enabling this policy, several considerations should be kept in mind:

1. All public host names for the Percussion server should be added after 'self' to make sure that requests from those hostnames are allowed.
2. If Templates are referencing external scripts or stylesheets from external CDN's, Web Servers, or HTTP end points, each of those endpoint hostnames needs to be included in the policy or the client browser will block requests to those resources. 
3. A more relaxed policy allows for simple configuration, with some protection, a stricter policy will provide the best security. 

More information on Content Security Policy options can be found on the Content Security Policy section of the MDN. 

Strict Transport Security

Strict Transport Security is a mechanism by which the server can tell the client web browser to automatically request content over https when it is originally requested over http.  There are some important considerations that may affect how the product is configured.  As a result, this header is turned off by default. 

Location: <installDir>/rxconfig/Server/server.properties

Setting: requireStrictTransportSecurity

Default: false

Setting: stricttransportsecuritymaxage

Default:  300

Strict Transport, also known as HSTS, includes an age option by which the client brower will cache the directive to redirect to https if an http request is made to the application server.  The default setting of 300 is extremely low and is intended for use while originally configuring the server to use this directive.  The lower value prevents remote client browsers from caching an incomplete or untested configuration. Enabling a longer value, such as a year, would be appropriate after the configuration has been tested.  

When enabling strict transport a review of the ports that are used in implementation are necessary.  The HSTS specifications do not take ports into account, and purely redirects based on the host name.  

The impact of this is that if a user accesses http://mypercussion:9992/ and HSTS is enabled, the web browser will automatically rewrite the request to https://mypercussion:9992/.  This will obviously fail as 9992 is an http port by default. 

As a result of this, we recommend that before enabling HSTS one of the following two configuration changes are made to your Percussion installation:

1. Re-configure Percussion to run on port 80 for HTTP and port 443 for HTTPS.
2. Re-Configure Percussion to run behind an HTTP and HTTPS proxy server on port 80 and 443 and ensure that end-users only access the server via the proxy. 

It is imporant to remember that HSTS is a client side directive. To configure a server side redirection to HTTPS see the Requiring HTTPS section below.  For more information on Strict Transport see the Strict Transport Security page on the MDN. 

Requiring HTTPS

Percussion can be configured to redirect requests to an HTTP to the Percussion HTTPS port on the server side.  This option is turned off by default as HTTPS is not configured in all Percussion installations. 

Location: <installDir>/rxconfig/Server/server.properties

Setting: requireHTTPS

Default: false

For more information on configuring HTTPS, please see the Enabling HTTPS page for Rhythmyx and the Applying an SSL Certificate to Percussion Page for CM1.

Note that all of the Secure Headers coverred in this page are applied when running under both the Jetty or JBOSS application servers. For Rhythmyx customers, Percussion strongly recommends running the product under the Jetty application server, as JBOSS is end of life and is no longer receiving security updates. CM1 customers will be upgraded to the Jetty application server as part of the 5.4 release.