Security

SoliDB includes robust built-in security features to protect your data and infrastructure from common attack vectors.

Authentication & Authorization

Feature	Description
JWT Authentication	All API endpoints require Bearer token authentication signed with HMAC-SHA256.
Random Admin Password	Default admin password is randomly generated on first startup and displayed in logs.
Secure Password Hashing	Passwords are hashed using Argon2id, a memory-hard algorithm resistant to GPU cracking.
API Keys	Long-lived keys for programmatic access, alternative to ephemeral JWT tokens.
Rate Limiting	Login attempts are limited to 5 per 60 seconds per IP address to prevent brute force attacks.

User & Role Management

SoliDB uses a granular Role-Based Access Control (RBAC) system. Users are assigned one or more roles, and roles define specific permissions to access databases and resources.

Users

Users are identified by a unique username. Each user can have multiple roles assigned to them.

Managed via /_api/auth/users
Password protected (Argon2id)
Can be assigned roles per-database

Roles

Roles are collections of permissions. SoliDB comes with built-in roles, but you can create custom roles with tailored permissions.

Managed via /_api/auth/roles
Granular permissions (Admin, Write, Read)
Scoped globally or to specific databases

Permission Structure

Permissions are defined by an action and a scope.

{
  "action": "write",       // admin, write, read
  "scope": "database",     // global, database
  "database": "products"   // Required if scope is "database"
}

Built-in Roles

Role	Permissions	Description
admin	All Permissions	Full access to all databases and system configuration (including user/role management).
editor	Read + Write (Global)	Can read and write to all databases, but cannot manage users or system settings.
viewer	Read (Global)	Read-only access to all databases.

Production Configuration

For production deployments, configure these environment variables to verify security and persistence:

setup.sh

# REQUIRED: Set a secure JWT secret (32+ characters)
# If not set, a random secret is generated on startup (invalidating tokens on restart)
export JWT_SECRET="your-secure-random-secret-here"

# OPTIONAL: Set admin password (otherwise randomly generated)
# Useful for automated deployments where you can't read logs
export SOLIDB_ADMIN_PASSWORD="your-secure-password"

Important Warning

If you do not set JWT_SECRET, all user sessions and API tokens will be invalidated every time the server restarts.

Cluster Security

For multi-node clusters, SoliDB uses a sheared secret keyfile to authenticate nodes.

# 1. Generate a secure keyfile (do this once)
openssl rand -base64 756 > solidb-keyfile
chmod 600 solidb-keyfile

# 2. Copy the keyfile to all nodes

# 3. Start with keyfile authentication
solidb --keyfile solidb-keyfile --peer node2:6746 --peer node3:6746

The cluster communication protocol uses HMAC-SHA256 to sign all handshake messages, ensuring that only nodes possessing the shared keyfile can join the cluster.

Built-in Protections

Request Body Limits

Global limit of 10MB for standard requests. Specialized endpoints (imports, blob uploads) allow up to 500MB. Attempts to send larger payloads are rejected with HTTP 413.

Query Timeout

SDBQL queries have a strict 30-second timeout. Long-running queries (e.g., infinite loops) are automatically terminated to free up server resources.

Header Injection Prevention

User-provided filenames in Content-Disposition headers are strictly sanitized to prevent HTTP header injection attacks.

Timing Attack Protection

API key validation uses constant-time string comparison algorithms to prevent side-channel timing attacks that could reveal key contents.

Recommendations

1 Use HTTPS in production. Put SoliDB behind a reverse proxy like Nginx, Caddy, or Apache to handle SSL/TLS termination.
2 Firewall internal ports. Restrict access to the replication port (default 6746) to trusted cluster nodes only.
3 Change the admin password immediately after your first login via the dashboard or API.
4 Monitor logs for repeated login failures, which may indicate a brute force attempt (mitigated by rate limiting, but still worth monitoring).