Securing SigningHub Desktop Web

Excluding API Response Headers

To allow SigningHub Web to insert its own response headers instead of relying on those coming from the API server, specific headers can be excluded using the following configuration in appsettings.Production.json:

"Headers": {
  "Excluded": [
    "Transfer-Encoding",
    "Date",
    "Server"
  ]
}

When defined, the listed headers are removed from the API response before reaching the client. This allows the SigningHub Web frontend to apply its own headers as needed.

This configuration is intended for internal use only. By default, SigningHub Web automatically adds the excluded headers (Transfer-Encoding, Date, and Server) to maintain expected behavior and compliance across environments.

Disable Enforced HTTPS Redirection

If you want to use HTTP instead of HTTPS, the following configurations are required:

Set the value for the https_redirect tag in the appsettings.Production.json file to false.

"https_redirect":  {
  "enabled":  "false"}

Cross-Site Request Forgery (CSRF)

The SigningHub implements an anti-forgery token to protect your application from CSRF attacks. The SigningHub implements this in the application by default, and no configurations are required.

CORS Policy

The Signinghub implements CORS policies to control how the resources are accessed from external domains. By default, everything is allowed, but it can be configured in appsettings.Production.json in the following section:

For "AllowedOrigins" , set the value of origins, e.g. "https://example.com". The SigningHub Web would only be accessible from the origins mentioned in the list. If it's not present, then SigningHub will work as of today and allow all origins by default.

HTTP Strict Transport Security (HSTS)

Signinghub implements HSTS to protect from protocol downgrade attacks and cookie hijacking by ensuring that browsers only communicate with the server over HTTPS. The following configurations can be set in appsettings.Production.json accordingly, and ExcludedHosts can be set explicitly as per need:

If this Optional parameter is specified, this rule applies to all of the site's sub-domains as well.

HTTP Public Key Pinning header

The HTTP Public-Key-Pins response header associates a specific cryptographic public key with a particular web server to reduce the risk of MITM attacks involving forged certificates. If one or several keys are pinned and none of them is used by the server, the browser will not accept the response as legitimate and will not display it. To enable Key Pinning, add the following header in the HTTP Response Headers of IIS against the SigningHub Desktop Web website:

pin-sha256: The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in future. max-age: The time, in seconds, that a browser should remember that this site is only to be accessed using one of the defined keys, e.g. 31536000.

includeSubDomains: If this Optional parameter is specified, this rule applies to all of the site's subdomains as well.

TLS Fallback SCSV

To work around interoperability problems with legacy servers, many TLS client implementations do not rely on the TLS protocol version negotiation mechanism alone. They will intentionally reconnect using a downgraded protocol if initial handshake attempts fail. Such clients may fall back to connections in which they announce a version as low as TLS 1.0 (or even its predecessor, Secure Socket Layer (SSL) 3.0) as the highest supported version. To avoid the TLS Fallback SCSV attacks, it is recommended to disable all TLS protocols except TLS 1.2. Click here for instructions to disable the weak protocols.

SSL Medium Strength Cipher Suites

SigningHub does not use the Medium Strength Ciphers (> 64-bit and < 112-bit key, or 3DES), so you can disable them to avoid any misuse. Click here for instructions to disable the weak or medium ciphers.

Hiding application errors and server information

Printing of an exception in the browser, server OS information, application data, or version number can be of great value for an attacker. By default, this is turned off to facilitate troubleshooting errors; however, when deployed in production, it should be turned on. It can be turned on by setting "DetailedErrors": true in the appsettings.Production.json.

Content Security Policy Header

This header helps to prevent code injection attacks like cross-site scripting and clickjacking by telling the browser which dynamic resources are allowed to load. The value of the Content-Security-Policy header is made up of x segments separated by a semicolon; self translates to the same origin as the HTML resource. With this minimum configuration, your HTML is allowed to fetch JavaScripts, stylesheets, etc. from the same domain that served the HTML referencing the resources. You won't be able to include external scripts from CDNs and similar. This header is added in SigningHub Admin>Configurations>Global Settings>Content Security Policy,, and you need to change the SigningHub URLs accordingly:

  1. Please update the below-mentioned placeholders in the CSP header: [API_URL] [WEB_URL] [ADSS_URL] (This is for local-side signing using ADSS Go>Sign)

  1. Add the following URLs in connect-src for Belgian eID Card, in addition to the above CSP headers: https://client.localmiddleware.be:20202/version https://client.localmiddleware.be:20202/status https://client.localmiddleware.be:20202/events https://client.localmiddleware.be:20202/session https://client.localmiddleware.be:20202/eID/signingSession https://client.localmiddleware.be:20202/eID/id https://client.localmiddleware.be:20202/eID/nonRepudiationCertificate https://client.localmiddleware.be:20202/eID/citizenCertificate https://client.localmiddleware.be:20202/eID/rootCertificate https://client.localmiddleware.be:20202/eID/signRsa

  1. Add the following URLs in child-src and the last one in script-src for Stripe, in addition to the above CSP headers: https://api.taxamo.com/ https://c.taxamo.com/ https://p.taxamo.com/ https://api.taxamo.com/js/v1/taxamo.all.js

  1. Add the following URLs in connect-src for T1C signing, in addition to the above CSP headers: https://t1c.t1t.io https://t1c.t1t.io:51983/info

This configuration lets your web application load resources and styles from its own domain, and scripts from http://apis.google.com, https://js.live.net and https://www.google-analytics.com

  1. The domain(s) added under the frame-ancestors are allowed to embed the Document Viewer within the iframe. Only the specified domains would be able to embed the Document Viewer within the iframe. Leaving this tag blank will allow all the domains to embed the Document Viewer.

CAPTCHA configurations

Google CAPTCHA must be configured in the SigningHub application to prevent brute force attacks. This can be configured in the SigningHub admin console under connectors and has to be set as the default Google CAPTCHA under Global Settings.

Enabling HTTP/2

To improve performance and security, SigningHub Web can be configured to use HTTP/2. This is supported on IIS 10 and above running on Windows Server 2016 or later.

  1. Open IIS Manager.

  2. Navigate to your SigningHub website.

  3. Select Bindings from the Actions pane.

  4. Edit the site’s HTTPS binding and ensure an SSL certificate is configured.

  5. Verify that the option Disable HTTP/2 is unchecked.

Once configured, SigningHub will automatically use HTTP/2 for all supported browsers.

PreviousSecuring SigningHub Admin APINextSecuring SigningHub Web API

Last updated

Was this helpful?