Security best practices

When a self-hosted SeekTable deployment is used only for internal company purposes (and access can be controlled via VPN), using the default configuration is generally sufficient. However, if an on-premises SeekTable instance is accessible from the internet and/or used to access reports containing sensitive data, it is highly recommend following these app configuration best practices to prevent potential security vulnerabilities:

• Important Set an unique (secret) in-app JWT signing key in the docker-compose.seektable.env app config file:

  SeekTable_ST__PivotDataService__Jwt__IssuerSigningKeyString=YOUR_SECRET_KEY_MIN_16_CHARS

  The same value should be specified in the docker-compose.pivotdataservice.env app config file:

  PivotDataService_Auth__Jwt__IssuerSigningKeyString=YOUR_SECRET_KEY_MIN_16_CHARS

  This JWT signing key is used internally for inter-service communication (SeekTable container ↔ PivotDataService container).
• Allow only HTTPS connections. For this purpose you need to use a reverse proxy server to handle incoming HTTPS traffic: this doc page explains how to setup NGINX as a reverse proxy (IIS can be used for the same purpose).
• Disable public sign-up form. This is possible only if your installation has activated "System/users admin" capability.
• Store in the DB only SHA256 hashes of user accounts 'access key' values in the docker-compose.seektable.env app config file:

  SeekTable_ST__Account__StoreAccessKeyHash=true

  Note: the login form may be disabled at all when AD/Entra ID SSO is configured.

In case of strong security requirements you can:

• enable JWT encryption for tokens generated by SeekTable app (SeekTable_ST__PivotDataService__Jwt__TokenDecryptionKeyString and SeekTable_ST__Api__Jwt__TokenDecryptionKeyString settings).
  If reports are embedded with JWT auth token is generated on your side and you can encrypt it too.
• force strong JWT signing/encryption (use SHA512/AES256 instead of SHA256/AES128, SeekTable_ST__PivotDataService__Jwt__CreateTokenStrongEncryption and SeekTable_ST__Api__Jwt__CreateTokenStrongEncryption setting).
• force 2FA login for all users (SeekTable_ST__Account__TwoFactorRequired setting)

Some technical details that may be important if you need to pass a security audit:

• Self-hosted SeekTable installation uses its own SQLite DB file (standard deployment / stored in a docker volume) or PostgreSQL DB (enterprise/cluster deployment). On-prem deployments are fully separated and isolated from the cloud SeekTable service.
• to make a full backup it is enough to make a copy of docker volumes (DB + uploaded CSV files).
• SeekTable uses a standard Microsoft library to generate (sign, encrypt) and validate JWT tokens (System.IdentityModel.Tokens.Jwt).
• SeekTable built-in sign-in (login box) uses a standard MVC Core cookie-based authentication provider.
• When a report is shared (with "Team Sharing" / published to web with a public link / embedded with iFrame) viewers cannot access cube's configuration details like connection string or SQL query template in any way.
• DB query can be affected only with explicitly-placed report parameters placeholders. SQL injections are not possible: parameters values are passed as ADO.NET command parameters (exception is usage of Sql.Raw function in the parameter's "Expression" - it should be used carefully).
• Self-hosted SeekTable doesn't collect any telemetry, and it doesn't require an internet connection to work. Online activation of paid subscriptions requires an internet connection only on the application start; offline activation is possible to avoid any external requests.