Documentation Index

Fetch the complete documentation index at: https://help.board.com/llms.txt

Use this file to discover all available pages before exploring further.

Security recommendations for On-premises Board installations

  • Published on Jul 1, 2026
  • 6 minute(s) read
Prev Next

This article gives security recommendations for On-premises Board installations.

Use this article as a security baseline for Board software installations. Your IT and security teams must review each setting and decide whether the setting is suitable for your environment.

This article covers:

Purpose and scope

These recommendations apply to the web server that hosts Board Web and to related application settings.

The recommendations do not replace your company security policies. Your IT and security teams are responsible for assessing the security impact of each setting in your environment.

Web server security

Board recommends deploying Board Web under Microsoft IIS for on-premises installations.

Use IIS to manage secure browser access to Board Web in a standard Windows Server environment. IIS lets you configure HTTPS bindings, SSL certificates, authentication, and application pool settings.

When you publish the Board Web site, bind an SSL certificate to the host name. This protects communication between client browsers and the web server through encryption.

Use a certificate that meets your company security requirements. Your IT and security teams must review the final IIS configuration and make sure it follows your company security policies.

Encryption

Use TLS 1.2 or higher to secure communication.

Disable outdated protocols on the server that runs Board Web and Board Engine:

  • SSL 2.0

  • SSL 3.0

  • TLS 1.0

  • TLS 1.1

Make sure Microsoft .NET Framework supports strong cryptography.

Windows uses the Secure Channel library to configure these settings. Starting with Windows Server 2016, TLS 1.2 is enabled by default. Always verify the current configuration in your environment.

Also review the cipher suites negotiated by the server. Remove deprecated cipher suites when your company security policy requires it.

Use strong TLS 1.2 cipher suites, such as:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Recommended TLS 1.3 cipher suites

Use strong TLS 1.3 cipher suites, such as:

TLS_AES_256_GCM_SHA384

TLS_AES_128_GCM_SHA256

Folder permissions

When you configure the Board Web site folder, grant permissions to the application pool identity.

The application pool identity usually belongs to the IIS_IUSRS Windows group.

Use these permissions as a baseline.

Folder

Required permissions

Reason

Main Board Web folder, such as C:\inetpub\wwwroot\BWEB

Read, Read and execute, List folder contents

Board Web must read and run the application files.

App_Data subfolder

Full control

Board Web must write log files and generate the certificate used to sign the JWT token that secures communication with Board Engine.

You can change the default logging folders for Board Web and its components in the related .config files

Mitigate IIS tilde enumeration

IIS tilde enumeration can expose short file names. To mitigate this risk, disable 8.3 file name creation.

Run this command in an elevated Command Prompt:

fsutil.exe behavior set disable8dot3 1

You can also set this registry key to 1:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3Name

Review this change with your IT team before you apply it. The setting can affect applications that depend on 8.3 file names.

Configure IIS response and debug settings

Step 1: Remove the Server response header

You can remove the Server response header to reduce the amount of IIS information exposed in HTTP responses.

  1. Open "IIS Manager".

  2. Select the Board Web site.

  3. Open "Configuration Editor".

  4. In "Section", select "system.webServer", "security", and then "requestFiltering".

  5. Set "removeServerHeader" to True.

  6. Apply the change.

Step 2: Disable debug mode

Disable debug mode for the Board Web application.

  1. Open "IIS Manager".

  2. Select the Board Web site.

  3. Open "Configuration Editor".

    1. In "Section", select "system.web".

  4. Set "compilation debug" to False.

  5. Apply the change.

Do not override the Content Security Policy

Do not create a custom Content Security Policy header in IIS for the Board Web site.

Board sets the Content Security Policy at code level. If you override the Content Security Policy in IIS, Board Web might not work correctly.

Configure Board Engine security settings

Make sure the following Board Engine security settings are in place:

Setting

Recommended value or action

Notes

ExtractWhiteList.config

Configure this file in the Board path, usually C:\Board.

Use this file to control allowed extract paths.

AllowServerSideCommands

Set to False in server_config_v2.xml.

This file is usually in the Board installation path.

License Level Check

Set to "High".

Review the setting with your Board Administrator.

Manage Password

Enable this setting.

Review the setting with your Board Administrator.

Web Application Firewall (WAF)

Board strongly recommends deploying a Web Application Firewall in front of the Board Web server, especially when Board Web is exposed to the Internet.

A Web Application Firewall inspects HTTP and HTTPS traffic. A tuned Web Application Firewall can block malicious requests before the requests reach IIS or Board Web.

The Web Application Firewall should run in reverse proxy mode or be integrated at the load balancer or edge layer.

Examples include:

  • Azure Application Gateway WAF

  • Azure Front Door WAF

  • F5 ASM

  • Cloudflare WAF

Web Application Firewall rollout

Introduce a Web Application Firewall in phases. Do not enable blocking mode in production before you validate normal Board traffic.

Blocking mode can affect valid Board traffic, including API calls and authentication flows.

Phase 1: Use detection mode

Start with Detection, Monitoring, or Audit mode.

In this phase, the Web Application Firewall inspects traffic and logs potential threats. The Web Application Firewall does not block requests.

Keep this mode active long enough to capture normal traffic patterns, such as:

  • User authentication

  • Cube execution and data refresh

  • Data extract operations

  • Administrative activities

  • Peak usage periods, such as month-end processing

Avoid short observation windows. Board traffic can vary by workload and timing.

Phase 2: Analyze logs and tune rules

Review Web Application Firewall logs to identify:

  • False positives

  • Rules that are triggered during normal operations

  • Anomalous patterns that can indicate real threats

Pay special attention to:

  • Encoded characters in requests

  • JSON payload inspection

  • JWT token exchanges

  • API endpoints used for communication between Board Web and Board Engine

If you find false positives:

  • Apply scoped exclusions for specific URLs, parameters, or rule IDs.

  • Avoid disabling full rule groups unless required.

  • Document each exclusion and the reason for the exclusion.

Phase 3: Move to prevention mode

After validation and tuning, switch the Web Application Firewall to Prevention or Blocking mode.

When possible:

  • Enable blocking by rule group instead of enabling all blocking at the same time.

  • Move to blocking mode during a low-traffic period.

  • Monitor logs closely during the first days after activation.

  • Keep a rollback plan ready in case valid traffic is affected.

Web Application Firewall protections

Configure the Web Application Firewall to protect against common web risks, such as:

  • OWASP Top 10 vulnerabilities, including SQL injection, Cross-Site Scripting, and command injection

  • HTTP protocol violations and malformed requests

  • Known attack signatures

  • Automated bot traffic

  • Brute force login attempts

  • Abuse of exposed endpoints

Use managed rule sets, such as the OWASP Core Rule Set. Keep the rule sets updated.

TLS handling with a Web Application Firewall

If TLS ends at the Web Application Firewall:

  • Enforce TLS 1.2 or higher.

  • Align cipher suites with your company security baseline.

  • Re-encrypt traffic between the Web Application Firewall and IIS when possible.

Do not lower security between the Web Application Firewall and backend servers.

Rate limiting and denial-of-service protection

Enable rate limiting to reduce the risk of:

  • Brute force login attempts

  • Credential stuffing

  • Layer 7 denial-of-service attacks

Set thresholds based on expected traffic volume and normal usage patterns.

Sudden spikes in POST requests or authentication attempts should trigger throttling or blocking rules.

IP filtering and geo restrictions

Where applicable, add these controls:

  • Restrict administrative endpoints to trusted IP ranges.

  • Use IP reputation filtering.

  • Apply geo restrictions when the application is intended for defined regions.

These controls support authentication and authorization. These controls do not replace authentication and authorization.

Header and response integrity

Make sure the Web Application Firewall does not reintroduce HTTP headers that you removed in IIS, such as the Server header.

Do not override security headers that Board defines at application level, such as the Content Security Policy.

Overriding these headers can affect Board Web functionality.

Logging, Monitoring and Ongoing Maintenance

Enable detailed Web Application Firewall logging.

Integrate logs with a central monitoring tool or SIEM (Security Information and Event Management) system where possible.

Review logs regularly for:

  • Blocked requests

  • Repeated attack patterns

  • Rule trigger frequency

  • Behavioral anomalies

Web Application Firewall configuration is not a one-time task. Repeat a validation cycle after:

  • Board upgrades

  • Infrastructure changes

  • Authentication changes

  • New API introductions