Security best practices

When a self-hosted SeekTable is used only for the company's internal purposes (and you can control the access with VPN) in most cases it is ok to use a default app configuration. However, if on-premise SeekTable is accessible from internet and/or used to access reports that contain sensitive data you may follow best practices to avoid many security vulnerabilities:

• 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).
• set an unique value for SeekTable_ST__PivotDataService__Jwt__IssuerSigningKeyString setting (the same value should be for PivotDataService_Auth__Jwt__IssuerSigningKeyString).
• disable public sign-up form (this is possible only if your installation has an active "System/users admin" subscription).
• enable storing of SHA256 hashes for user accounts 'access key' values with SeekTable_ST__Account__StoreAccessKeyHash setting. Login form may be disabled at all when Active Directory 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:

• SeekTable installation uses its own SQLite DB file (stored in a docker volume). It is a fully separated and isolated from the cloud SeekTable.
• 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.