Advanced recommendations

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Best practices in the production environment > Security hardening at the IIS >

Advanced recommendations


This section presents security recommendations to apply in the Bizagi Work portal which are relevant to Bizagi's configuration (application hardening).


To carry out the recommendations presented below, you should have already followed what described at Intermediate recommendations.



The following recommendations apply when Bizagi runs on a .NET platform independently from the Web server IIS version on which it runs.

In this section, we describe the configuration for an IIS Web server version 7.5, and such hardening is carried out according to the IIS capabilities.


Advanced recommendations

These apply to your testing or pre-production (when you use one) environments as well.

This section presents specific steps to mitigate a range of vulnerabilities.



For some of these steps, make sure you have installed the URL Rewrite module for the IIS.

The module in its 2.0 version (for IIS versions 7, 7.5 and 8) is a plugin that can be downloaded directly from


1. Rewriting values in server variables

We recommend that you configure rules that rewrite certain values which may leak information regarding the server (this action seeks to mitigate the vulnerability known as information leakage).

Values providing IIS server information are disclosed by default in the following variables: RESPONSE_SERVER, RESPONSE_X-ASPNET-VERSION, and RESPONSE_X-POWERED-BY.


To rewrite these values, perform the following steps:


Use the URL Rewrite option for the Bizagi Work portal (at the site folder level). Select View Server variables to make sure you have placed those three variables to rewrite.


If the option is not available in the IIS you must install it. Refer to URL rewrite.




Use the Add option three times to include the variables one by one. In the end you should be able to see them all listed:




Next, click Back to rules to add the rules that will rewrite values.

For each variable (RESPONSE_SERVER, RESPONSE_X-ASPNET-VERSION, and RESPONSE_X-POWERED-BY), click Add rule(s).. and select the blank type of rule for the Outbound category.




The properties for each rule will be :

Name: A name according to your choice.

Precondition: None.

Matching scope: Server variable.

Variable name: Enter the name of the corresponding variable to rewrite (RESPONSE_SERVER, RESPONSE_X-ASPNET-VERSION, or RESPONSE_X-POWERED-BY).

Variable value: Matches the pattern.

Using: Regular expression.

Pattern: .+

Ignore case: On.




Action type: rewrite

Value: EMPTY.

Replace existing server variable value: On




You should be able to see the rules listed for the three variables:




Similarly, from a browser, you should be able to inspect these values as sent by the server:




2. Using secure headers

We recommend that you establish secure headers to avoid disclosing information which may be used for potential attacks (to mitigate a vulnerability known as ClickJacking).

Configure the header by using the following values:











1; mode=block


Strict-Transport-Security: max-age=31536000; includeSubDomains


You must define your customized structure based on the Policy


NOTE: Here you may add URLs different from the application URL (depicted as "self"). For more information, refer to


To accomplish this,  perform these steps:


Use the HTTP Response Headers option for the Bizagi Work portal (at the site folder level), to add each header with the value as listed above, using the Add option:




Once you have done this, you should be able to see them all listed:





For Bizagi, security is an aspect of critical importance.

Therefore, Bizagi periodically releases new versions which feature improvements and fixes for issues detected in previous versions.

Fixes for those detected issues may include specific solutions for security vulnerabilities.


We strongly recommend that you consider a periodic upgrade of your solution to Bizagi's newest releases, always following the usual guidelines for an upgrade procedure such as:

Plan, coordinate and appropriately test each upgrade.

Upgrade all environments (development, testing, pre-production when applicable, and production).

Before starting the upgrade, take proper contingency measures (e.g backups).

Evaluate customizations or additional security configurations such as the ones listed above, so stakeholders are aware that it is part of the plan to reconfigure certain features after the upgrade.



When you have customizations or have applied hardening measures such as the ones above, follow one of these options when carrying out a version upgrade:


1. If you use the Bizagi Management Console, back up your customizations before starting. After the upgrade, reconfigure each measure and verify they are still applied.

By default, an upgrade done through the Management Console does not check whether you have done modifications to the original files and file structure.


2. Do the upgrade through a manual procedure (without using Bizagi Management Console).

If you do, consider all the relevant components and files that you need to replace manually for the Work Portal and Scheduler, while avoiding overwriting your configured customizations or the already applied hardening measures.


For highly critical security issues, Bizagi may issues hot fixes and recommend that you apply them without waiting for a newer version.