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
- 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
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 (
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,
- force 2FA login for all users (
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.