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.
|
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.
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.
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.
|
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.
|
The Content Security Policy is configured exclusively in the environment where it is defined, when the project is deployed. You should define a Content Security Policy per environment, using the corresponding tab. |
Considerations for CSP Configuration
To ensure that the deployment package contains the Content Security Policy (CSP) settings, check the Environment parameters property box within the Advanced settings in the export window. To make the configuration complete the following steps:
1.In Bizagi Studio navigate to the Export/Import tab and select Export
2.In the new window, go to the Advanced section and check the Environment Parameters property.
Keep in mind the following conditions:
•In the first deployment, the configuration will be updated in the target environment.
•If in the target environment no changes have been made to the previously deployed configuration of the CSP, a new deployment package containing changes to it will be update the target environment.
•If you have made changes to the CSP configuration in the Test or Production environment, using the Management Console(MC), a new package with changes to the CSP will be ignored. Modifications to the CSP from now on must be made directly in the MC.
Next steps
Once you have finished the Content Security Policy configuration, you can install your widgets, or configure your attended bots.
Last Updated 1/31/2023 4:38:29 PM