> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Secure your IIS server

> Harden the IIS server hosting ABBYY FlexiCapture 12 with security headers like CSP and HSTS, DDoS protection, strong TLS ciphers, and web.config rules.

When ABBYY FlexiCapture 12 is deployed, the default IIS security configuration settings are used. You can also set up additional rules for specific requests to make your web server more secure.

## Content-Security-Policy header

Content Security Policy (CSP) is a security standard used by modern browsers to protect against data injection attacks, such as cross-site scripting (XSS). CSP uses a whitelist to determine which resources are safe to load and ignores unverified sources. It also logs any attempts to bypass the security policy.

To make use of this policy, the server must have a Content-Security-Policy HTTP header with one or more directives set up, with each directive responsible for a specific resource type. Directives set out a security policy by declaring rules for resources.

To set up CSP for your browser, add the following code into your `web.config` file:

```
<system.webServer> 
<httpProtocol> 
<customHeaders> 
<add name="Content-Security-Policy" value="default-src https: data: 'unsafe-inline' 'unsafe-eval'" /> 
</customHeaders> 
</httpProtocol> 
</system.webServer>
```

<Note>
  If you need to integrate ABBYY FlexiCapture with third-party systems and require access to other hosts, specify them in the `web.config` file. Be sure to check the operation of the software each time you change your security configuration settings.
</Note>

For more information about the Content-Security-Policy header, see [this website](https://content-security-policy.com/).

## HTTP Strict-Transport-Security header

HTTP Strict-Transport-Security (HSTS) is a website protection mechanism that restricts all interactions between the browser and the website to a secure connection using the SSL protocol. A web server that has HSTS set up contains an instruction for the browser to exclusively use HTTPS and forbids it from using HTTP. HSTS is primarily used to fend off interception attacks involving queries and responses, for example, MITM (Man-In-The-Middle) attacks.

To be able to use this security policy, you need to use URL address rewrite rules to add a Strict-Transport-Security (STS) header to HTTP responses. This is necessary to prevent unwanted HTTP queries and redirect all HTTP traffic to HTTPS (based on the logic set out in the rules). To set up the rules, you need to install the URL Rewrite module. For more information, see the [Microsoft website](https://docs.microsoft.com/ru-ru/iis/extensions/url-rewrite-module/using-the-url-rewrite-module).

To set up HSTS for your browser, add the following code into your `web.config` file:

```
<rule name="Add the STS header in HTTPS responses">
<match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" />
</conditions>
<action type="Rewrite" value="max-age=31536000" />
</rule>
```

<Note>
  The `max-age` directive specifies the time period (in seconds) during which the rule will be applied. The value specified in the code snippet above equals a period of one year.
</Note>

For more information about HSTS, see the [Microsoft website](https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#challenges-on-enabling-hsts-before-iis-100-version-1709).

## X-Powered-By and X-AspNet-Version headers

Apart from HTTP headers that are essential for improving the security of your web server, there are also headers that are optional. Often, such optional headers are not governed by any standards and their use increases the amount of traffic generated by each HTTP query, making it easier to carry out malicious attacks.

The following are two such optional headers:

* X-Powered-By is an HTTP header that contains information about various technologies used by the web server.
* X-AspNet-Version is an HTTP header that contains information about the ASP.NET version that is used to deploy applications on the web server.

By default, both X-Powered-By and X-AspNet-Version are included in server responses. We recommend that you disable these headers, since providing identifying information can pose a security threat.

To remove the X-Powered-By header from the IIS configuration, paste the following code into your `web.config` file:

```
<httpProtocol> 
<customHeaders> 
<remove name="X-Powered-By" />   
</customHeaders></httpProtocol>
```

To remove the X-AspNet-Version header from your IIS configuration, paste the following code into your `web.config` file:

```
<httpRuntime enableVersionHeader="false" />
```

## X-XSS-Protection header

X-XSS-Protection is an HTTP header that is used by browsers to prevent Cross-Site Scripting attacks. The header works by enabling an XSS filter, which intercepts unwanted attempts to insert malicious third-party code into web pages opened on a browser.

X-XSS-Protection is compatible with the following browsers: Internet Explorer 8+, Chrome, and Safari. However, most modern browsers use a stricter security policy (for example, Content-Security-Policy), which makes this header necessary only if you are using an older browser that does not support CSP.

To enable the X-XSS-Protection header for your browser, copy the following code to your `web.config` file:

```
<system.webServer> 
<httpProtocol> 
<customHeaders> 
<add name="X-XSS-Protection" value="1; mode=block" /> 
</customHeaders> 
</httpProtocol> 
</system.webServer>
```

## X-Content-Type-Options header

X-Content-Type-Options is an HTTP header that is used by browsers to prevent attacks that exploit MIME (Multipurpose Internet Mail Extensions) vulnerabilities. MIME is an Internet standard for content that is sent over an internet connection. All files served by the web server are processed by browsers in a manner that depends on the MIME type of those particular files. Browsers determine the resource type by either using the Content-Type response, or by inspecting the resource contents, which makes it possible for attackers to mask HTML files as files of a different type.

The only directive available for this header is the `nosniff` directive. It instructs browsers to use only the MIME type that was specified by the web server.

To enable the X-Content-Type-Options header for your browser, paste the following code into your `web.config` file:

```
<system.webServer> 
<httpProtocol> 
<customHeaders> 
<add name="X-Content-Type-Options" value="nosniff" /> 
</customHeaders> 
</httpProtocol> 
</system.webServer>
```

## Server header

Server Header is a response header that contains information about the application used by the source server to process a request (for example, the version number of the application). Potential availability of this kind of information to third parties is a security threat. For this reason, we recommend deleting the contents of the Server Header.

To delete the contents of the Server Header, add the following code into your `web.config` file:

```
<rewrite>  
     <outboundRules rewriteBeforeCache="true"> 
    <rule name="Remove Server header"> 
      <match serverVariable="RESPONSE_Server" pattern=".+" /> 
      <action type="Rewrite" value="" /> 
    </rule>   
</outboundRules> 
</rewrite>
```

If you are using IIS 10.0, Windows Server 2016 or later, use the following code instead:

```
Set-WebConfigurationProperty  
-pspath 'MACHINE/WEBROOT/APPHOST'   
-filter "system.webServer/security/requestFiltering"  
-name "removeServerHeader"  
-value "True"
```

<Note>
  The settings described above require the URL Rewrite module to be installed. For more information, see [the Microsoft documentation](https://docs.microsoft.com/ru-ru/iis/extensions/url-rewrite-module/using-the-url-rewrite-module).
</Note>

## X-Frame-Options header

By default, it is allowed to embed ABBYY FlexiCapture Web Stations via iFrame into other companies' web sites. However, if you become aware of framesniffing, you can do the following to prevent content from being hosted in a cross-domain iFrame:

<Steps>
  <Step title="Select the site">
    In the **Connections** pane on the left side, expand the **Sites** folder and select the site that you want to protect.
  </Step>

  <Step title="Open HTTP Response Headers">
    Double-click the **HTTP Response Headers** icon in the feature list in the middle.
  </Step>

  <Step title="Add a header">
    In the **Actions** pane on the right side, click **Add**.
  </Step>

  <Step title="Set the X-Frame-Options value">
    In the dialog box that opens, type **X-Frame-Options** in the **Name** field and type **SAMEORIGIN** or **DENY** in the **Value** field.
  </Step>
</Steps>

For more information, see [the Microsoft documentation](https://support.microsoft.com/en-us/office/mitigating-framesniffing-with-the-x-frame-options-header-1911411b-b51e-49fd-9441-e8301dcdcd79).

## Slow HTTP POST vulnerability

Slow HTTP POST vulnerability is a variation of a slow HTTP Denial of Service attack (DoS), otherwise referred to as the Slowloris HTTP attack. In a slow HTTP POST attack, the attacker declares a large amount of data to be sent in an HTTP POST request and then sends it very slowly. To resolve the Slow HTTP POST vulnerability on the customer's side, it is necessary to set up Web Limits in the IIS configs on the machines where the Application Server is installed. The limits should be set for the following parameters:

* `ConnectionTimeout`
* `MinFileBytesPerSec`

For more information about Web Limits, see [the Microsoft documentation](https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/weblimits).

## Use HTTPS instead of HTTP

The HTTP protocol lacks security mechanisms to encrypt data, whereas HTTPS provides an SSL or TLS Digital Certificate to secure the communication between server and client. Ensure that all traffic between the user’s browser and the web server is forced over an encrypted channel using HTTPS. HTTP operates on port 80 by default. Close this port to prevent the use of HTTP.

## Use an up-to-date TLS version and strong ciphers

TLSv1.1 is considered a weak encryption protocol. An attacker can exploit weaknesses in the protocol to read secure communications or maliciously modify messages. We recommend that you always use the latest possible version of TLS and only strong ciphers (a list of appropriate ciphers can be found at [https://wiki.mozilla.org/Security/Server\_Side\_TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)). To configure the SSL Cipher via group policy:

<Steps>
  <Step title="Open the Group Policy editor">
    At a command prompt, enter `gpedit.msc`. The **Group Policy Object Editor** appears.
  </Step>

  <Step title="Open the SSL configuration settings">
    Expand **Computer Configuration, Administrative Templates**, **Network**, and then click **SSL Configuration Settings**.
  </Step>

  <Step title="Open the cipher suite order">
    Under **SSL Configuration Settings**, click the **SSL Cipher Suite Order** setting.
  </Step>

  <Step title="Scroll to the instructions">
    In the **SSL Cipher Suite Order** pane, scroll to the bottom of the pane.
  </Step>

  <Step title="Modify the setting">
    Follow the instructions labeled **How to modify this setting**.
  </Step>
</Steps>

You will need to restart the computer for the changes to take effect.

## Protection against distributed denial-of-service attacks

Distributed denial-of-service (DDoS) attacks involve overloading an application with HTTP requests, causing a significant increase in the amount of traffic and making the application inaccessible to legitimate users. It may not be easy to detect such attacks, as it is often difficult to distinguish between legitimate and malicious traffic.

To protect your web server from DDoS attacks, we recommend that you set up your IIS server to block access to your application if someone exceeds either the allowed number of requests over a certain period of time or the allowed number of concurrent requests.

To set up DDoS protection in IIS as described above, do the following:

<Steps>
  <Step title="Launch IIS Manager">
    Launch IIS Manager.
  </Step>

  <Step title="Open IP Address and Domain Restrictions">
    Select your website in the tree view and double-click the **IP Address and Domain Restrictions** icon on the site home page.
  </Step>

  <Step title="Edit the dynamic restriction settings">
    In the **Actions** pane, click **Edit Dynamic Restriction Settings**.
  </Step>

  <Step title="Choose a deny method">
    In the dialog box that opens, select the preferred method: **Deny IP Address based on the number of concurrent requests** or **Deny IP Address based on the number of requests over a period of time**.
  </Step>

  <Step title="Save the settings">
    Click **OK**.
  </Step>
</Steps>

In the IIS server settings, you can also restrict access to your application from specific IP addresses and specify the type of action that the server should perform when attempts are made to access your application from restricted IP addresses:

<Steps>
  <Step title="Launch IIS Manager">
    Launch IIS Manager.
  </Step>

  <Step title="Open IP Address and Domain Restrictions">
    Select your website in the tree view and double-click the **IP Address and Domain Restrictions** icon on the site home page.
  </Step>

  <Step title="Edit the dynamic restriction settings">
    In the **Actions** pane, click **Edit Dynamic Restriction Settings**.
  </Step>

  <Step title="Choose a deny action">
    In the dialog box that opens, select the type of action from the **Deny Action Type** drop-down list.
  </Step>

  <Step title="Save the settings">
    Click **OK**.
  </Step>
</Steps>

For cases where multiple HTTP requests are sent by multiple users from a single IP address, enable proxy mode in the IIS server settings. Doing so will let the proxy server pass the `x-forwarded-for` header to the web server to help identify the user.

To enable proxy mode, do the following:

<Steps>
  <Step title="Launch IIS Manager">
    Launch IIS Manager.
  </Step>

  <Step title="Open IP Address and Domain Restrictions">
    Select your website in the tree view and double-click the **IP Address and Domain Restrictions** icon on the site home page.
  </Step>

  <Step title="Edit the feature settings">
    In the **Actions** pane, click **Edit Feature Settings**.
  </Step>

  <Step title="Enable proxy mode">
    In the **Edit IP and Domain Restriction Settings** dialog box, select **Enable Proxy Mode**.
  </Step>

  <Step title="Save the settings">
    Click **OK**.
  </Step>
</Steps>

For more information about using IIS to restrict access to your application from certain IP addresses, see [the Microsoft documentation](https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-dynamic-ip-address-restrictions).

<Note>
  Using the proxy mode for handling large amounts of traffic may affect system performance and make it harder for legitimate users to access your application.
</Note>