Cross-site scripting (XSS) vulnerabilities are a severe threat for all high profile web applications like CoreMedia Studio. While conscientious output escaping always has to be the first choice in order to avoid cross-site scripting attacks, most modern web browsers offer a new standard called Content Security Policy (CSP) as a second line of defense (see http://www.w3.org/TR/CSP/).

Default Policy

The standard Blueprint CoreMedia Studio enables Content Security Policy by default. It configures at least the following default CSP directives in the browser.

default-src 'none';
style-src 'self' 'unsafe-inline';
script-src 'self' 'unsafe-eval';
img-src 'self';
connect-src 'self';
object-src 'self';
font-src 'self';
media-src 'self';
manifest-src 'self';
frame-src <YOUR_PREVIEW_ORIGIN>

The configuration represents the minimum set of directives to comply with the Studio's and its third-party library requirements. Both, the unsafe-inline value of the style-src directive and the unsafe-eval value of the script-src directive are required by Ext JS.

Customize Policy

Each of the CSP directives that are included in the default configuration plus the report-uri directive can be easily customized.

Caution

Note, that weakening the policy settings can have severe effects on the application's security. Especially re-enabling inline script execution is considered harmful as it thwarts all efforts to prevent XSS.

Customization is done via a set of studio.security.csp.* properties in the WEB-INF/application.properties property file of the Studio Server web application. Each property is responsible for one Content Security Policy directive.

Note

Please note that for legacy reasons the configuration needs to be done in the Studio Server. The Studio Client will reuse the CSP directives by sending a request to the Studio Server and dynamically creating a meta HTML element which adds the directives before the actual Studio Application is bootstrapped.

Here is an example how an adapted property would look like.

studio.security.csp.objectSrc='self',www.exampleDomain.com

Using frame-ancestors directive

The frame-ancestors directive is used to defend clickjacking attacks. Due to the way the Studio Client defines its CSP directives, it cannot be configured via WEB-INF/application.properties. This is because the CSP standard does not support setting this directive in meta HTML elements.

In order to configure the directive you need to adjust the configuration of the web server so it provides a corresponding CSP HTTP header. Our default docker deployment will already set the frame-ancestors to 'self'.

Please note that the frame-ancestors directive is part of the Content Security Policy Level 2 standard which is not yet supported by all the browsers that support Content Security Policy Level 1. If required, similar functionality can be achieved for 'legacy' browsers by setting an appropriate X-Frame-Options header in the web server delivering the Studio Client.

Write CSP Compliant Code

According to the default policy, inline JavaScript will not be executed. This restriction bans both inline script blocks and inline event handlers (for example onclick="..."). The first restriction wipes out a huge class of cross-site scripting attacks by making it impossible to accidentally execute scripts provided by a malicious third-party. It does, however, require a clean separation between content and behavior (which is good practice anyway). The required code changes for inline JavaScript code can be summarized as follows:

CSP violations can be easily discovered by monitoring the browser console. All violations are logged as errors including further details about the violation type and culprit.

Customize CSP Mode

CoreMedia Studio can run in one of four supported CSP modes.

The configuration is done via the studio.security.csp.mode key of the WEB-INF/application.properties property file of the Studio Server web application.