Content Security Policy definition

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Security definition >

Content Security Policy definition

Overview

The Content Security Policy is an HTTP header that adds an additional layer of security to web pages. The Content Security Policy reduces Cross Site Scripting attacks, or Click Jacking, and also let users restrict different resources (JavaScript, CSS, etc.) that a browser might load in a specific page. With this header, users can define which resources can be loaded when using Widgets and Attended bots. The following article shows how to use the Content-Security-Policy within Bizagi for enabling the contents from both of the components mentioned before.

 

Content Security Policy

The Content Security Policy is an HTTP header that adds an additional layer of security to web pages. By configuring this header, users can allow or deny different resources that can be loaded in the Work Portal, such as JavaScript calls, or CSS components. The Content Security Policy includes different directives, which are used depending on the resource you want to manage.  The main directives are shown in the following table:

 

Directive

Description

default-src

Defines the default policy for fetching JavaScript, Images, CSS, Fonts, AJAX requests, Frames and Media resources. This directive basically works as a fallback for some of the other directives. However, not all directives fallback to it.

script-src

Defines valid sources of JavaScript.

style-src

Defines valid sources of CSSs or stylesheets.

img-src

Defines valid sources of images.

connect-src

Applies to XMLHttpRequest, WebSocket, fetch(), <a ping> or EventSource. If not allowed, the browser shows a 400 HTTP code.

font-src

Defines valid sources of font resources.

object-src

Defines valid sources of plugins (<object>, <embed>, <applet>).

media-src

Defines valid sources of audio and video (<audio>, <video>).

frame-src

defines valid sources for loading frames.

 

To see the complete list of directives, click here.

 

Each of the directives may include one or more references, that are the ones used to allow the access to different sources. Some of the common references for the directives are:

 

Reference

Description

Example

*

Used as a wildcard. It allows any URL except the data:, blob: and the filesystem: schemes.

script-src *

'none'

Prevents loading resources from any source.

object-src 'none'

'self'

Allows loading resources from the same origin (host, and port).

default-src 'self'

data:

Allows loading resources via the data scheme (e.g. Base64 encoded images).

img-src data:

specificDomain.com

Allows loading resources from the specific domain

media-src specificDomain.com

*.example.com

Allows loading resources from any subdomain under example.com.

img-src *.example.com

https:

Allows loading resources only over HTTPS on any domain

object-src https:

'unsafe-inline'

Allows use of inline source elements such as style attribute, onclick, or script tag bodies (depends on the context of the source it is applied to) and javascript: URIs

script-src 'unsafe-inline'

'unsafe-eval'

Allows unsafe dynamic code evaluation such as JavaScript eval()

script-src 'unsafe-eval'

 

To see the complete list of references, click here.

 

note_pin

If a directive includes more than one resource, they can be separated by space, unless it is 'none', which must be the only reference in the directive.

when defining the Content Security Policy it is not necessary to include all the directives. It is recommended to include the default-src, and only those where you need to grant an access are required. For example, if you need to grant access to a source that loads resources of the script-src, style-src and img-src directives, only those should be included.

 

Content Security Policy in Bizagi Studio

By default Bizagi includes a definition for the Content Security Policy, which is the following:

 

default-src 'self' data: blob:;

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

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

img-src 'self' data: blob:;

font-src * 'unsafe-inline' data: blob:;

 

However, when using attended bots and widgets that load content from an external source, it is needed to change this header. For example, if a widget uses the script-src, style-src and img-src directives, only those should be included and/or modified.

 

default-src 'self' data: blob:;

script-src 'self' 'unsafe-inline' 'unsafe-eval' [widgetScriptURL];

style-src 'self' 'unsafe-inline' [widgetStyleURL];

img-src 'self' data: blob: [widgetImgURL];

 

where:

[widgetScriptURL]: should be the URL from which the widget uses its scripts.

[widgetStyleURL]: should be the URL from which the widget uses its styles.

[widgetImgURL]: should be the URL from which the widget takes its images.

 

To change the Content Security Policy, it is necessary to do it through Bizagi's Environment options. The following section shows how to define a new Content Security Policy in Bizagi Studio.

 

Content Security Policy for attended bots

The following is the definition of the Content Security Policy for attended bots:

 

default-src http://127.0.0.1:2323 [http://www.yourorchestrator.com] ‘self’ data: blob:;

script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’;

style-src ‘self’ ‘unsafe-inline’ blob:;

img-src ‘self’ data: blob:;

font-src * ‘self’ ‘unsafe-inline’ data:;

 

where [http://www.yourorchestrator.com] is the orchestrator's URL that you want to use.

 

Content Security Policy for widgets

The definition of the Content Security Policy for each widget is specifies in its own documentation. Follow the steps below for configuring the header, but keep in mind that you need to replace its definition with the one located in the widget's documentation.

 

Content Security Policy for more than one resource

If your project includes more than one widget, or a widget and attended bots, you only need to configure one Content Security Policy. For example, if you need to use one widget that uses the script-src, style-src and img-src directives; and the RPA bots, the Content Security Policy definition would be as follows:

 

default-src http://127.0.0.1:2323 [http://www.yourorchestrator.com] 'self' data: blob:;

script-src 'self' 'unsafe-inline' 'unsafe-eval' [widgetScriptURL];

style-src 'self' 'unsafe-inline' blob: [widgetStyleURL];

img-src 'self' data: blob: [widgetImgURL];

font-src * ‘self’ ‘unsafe-inline’ data:;

 

Where:

http://127.0.0.1:2323 and [http://www.yourorchestrator.com] correspond to the attended bots configuration parameters. Bear in mind that you need to replace [http://www.yourorchestrator.com] with your Orchestrator's URL.

[widgetScriptURL], [widgetStyleURL] and [widgetImgURL] correspond to the widget configuration parameters. Bear in mind that you need to replace this parameters with the URLs from which the widget loads its content.

 

What you need to do

To configure the Content Security Policy in Bizagi Studio, complete the following steps:

 

1.In Bizagi Studio, go to the Configuration tab and select Environment.

 

CSP01

 

2.In the new window, go to the custom tab. Here, you can define new custom parameters for each of the environments. Click the New button to create a new custom parameter.

 

CSP02

 

3.When creating a new parameter, you must define a name, a value and a description. To configure the Content Security Policy, use the following parameters:

oName: Content-Security-Policy.

oDefault value: use a valid content security policy definition, depending on whether you are going to use an attended bot or a widget.

oDescription: a description for your new parameter.

 

CSP03

 

note_pin

Make sure to define correctly the Content Security Policy. If the value of the parameter has an incorrect syntax, the parameter will be ignored and the policy will allow unrestricted access.

 

4.When you finish, click Ok. The new parameter will be shown in the corresponding environment.

 

CSP04

 

note_pin

The Content Security Policy will be configured only in the environment where it was defined and is not considered when the project is deployed. If you want to define a Content Security Policy for another environment, you have to configure it in the corresponding tab.

 

Next steps

Once you have finished the Content Security Policy configuration, you can install your widgets, or configure your attended bots.