Skip to content
HeliosDB HeliosDB Lite

Security Policy

Reporting a Vulnerability

If you discover a security vulnerability in HeliosDB Lite, please report it by emailing:

security@heliosdb.com

Please do not disclose security vulnerabilities publicly.

We will acknowledge receipt of your vulnerability report within 48 hours and send you regular updates on our progress. If you’re curious about the status of your report, please feel free to email us again.

What to Include

Please include the following information in your report:

  • Description of the vulnerability
  • Steps to reproduce the issue
  • Potential impact
  • Any suggested fixes (optional)
  • Your name/handle for credit (optional)

Security Model

Threat Model

HeliosDB Lite is designed as an embedded database for trusted applications. Our security model assumes:

In Scope:

  • Protection against SQL injection
  • Protection against buffer overflows and memory corruption
  • Protection against resource exhaustion (DoS)
  • Secure encryption of data at rest
  • Safe handling of untrusted SQL queries
  • Safe handling of untrusted data inputs

Out of Scope (in embedded mode):

  • Network-based attacks (no network server in embedded mode)
  • Multi-tenant isolation (single-tenant embedded mode)
  • Authentication/authorization (application responsibility)

Security Features

1. Memory Safety

  • Zero unsafe code in production codebase
  • Rust’s memory safety guarantees prevent:
    • Buffer overflows
    • Use-after-free
    • Null pointer dereferences
    • Data races

2. SQL Injection Protection

  • SQL parser validation using industry-standard sqlparser-rs
  • No string concatenation for query building
  • Parameterized queries ($1, $2, …) over the PostgreSQL wire protocol and the REST API
  • SQL injection tests

3. Cryptography

  • AES-256-GCM for data encryption (AEAD)
  • Argon2 for password-based key derivation
  • Random nonce generation (no nonce reuse)
  • Authenticated encryption (tamper detection)

Cryptographic Libraries:

  • aes-gcm 0.10 - AES-256-GCM implementation
  • ring 0.17 - Cryptographic primitives
  • argon2 0.5 - Password hashing
  • rustls 0.23 - TLS implementation

4. Input Validation

  • Bounds checking on all inputs
  • Type validation before operations
  • Division by zero protection
  • Integer overflow checking (debug builds)

5. Error Handling

  • No panics in production code
  • Typed errors
  • No information leakage in error messages
  • Proper error propagation

6. Resource Management

  • Automatic resource cleanup (RAII)
  • Per-user memory limits, query timeouts and result-row caps ([resource_quotas])
  • Connection limits ([server] max_connections, default 100)

Security Best Practices

For Application Developers

1. Data Encryption

Enable AES-256-GCM encryption at rest in the configuration file and keep the key out of it:

[encryption]
enabled = true
key_source = { Environment = "HELIOSDB_ENCRYPTION_KEY" }
Terminal window
export HELIOSDB_ENCRYPTION_KEY="$(openssl rand -hex 32)"
export HELIOSDB_JWT_SECRET="$(openssl rand -hex 32)"
heliosdb-lite start --data-dir ./data --config heliosdb.toml

Best Practices:

  • Generate keys with a cryptographically secure random source
  • Store keys in a secret manager, never in the configuration file or in source control
  • Back up the key separately from the data; data encrypted with a lost key cannot be recovered
  • Rotate keys for long-lived data

2. SQL Query Safety

Never build SQL by concatenating user input. Send values as parameters with your PostgreSQL driver:

import psycopg


with psycopg.connect("host=127.0.0.1 port=5432 user=app") as conn:
    # SAFE: the value travels as a bound parameter
    conn.execute("SELECT * FROM users WHERE name = %s", (user_input,))


    # UNSAFE: string formatting lets input change the statement
    # conn.execute(f"SELECT * FROM users WHERE name = '{user_input}'")

Best Practices:

  • Use bound parameters for every value that comes from a user
  • Limit query complexity in user-facing features
  • Set query timeouts for user queries
  • Log suspicious query patterns

3. Resource Limits

Cap what a single user or query can consume:

[resource_quotas]
memory_limit_per_user_mb = 1024
max_concurrent_queries = 100
query_timeout_secs = 30
max_result_rows = 10000


[server]
max_connections = 100

Best Practices:

  • Set query timeouts and result-row caps for user-facing workloads
  • Monitor memory usage
  • Rate-limit clients at the application or a reverse proxy
  • Set maximum database size limits

4. Error Handling

Best Practices:

  • Log errors for debugging, without sensitive data
  • Return sanitized errors to users
  • Don’t expose internal details in error messages

Dependency Security

Dependency Auditing

We use cargo-audit and cargo-deny to check for known vulnerabilities:

Terminal window
# Install tools
cargo install cargo-audit cargo-deny


# Run audits
cargo audit
cargo deny check

Dependency Policy

  • Only use crates from crates.io (no git dependencies in production)
  • Prefer well-maintained crates with security audits
  • Avoid dependencies with known vulnerabilities
  • Keep dependencies up-to-date
  • Review dependency changes in PRs

CI/CD Security

Our CI/CD pipeline includes:

  1. Dependency Audit - Check for known vulnerabilities
  2. Supply Chain Security - Verify dependency licenses and sources
  3. Secret Scanning - Detect committed secrets
  4. Code Security Analysis - static analysis security lints
  5. SAST Analysis - Static analysis for unsafe code
  6. Fuzz Testing - Randomized testing for edge cases
  7. Container Security - Scan Docker images
  8. CodeQL Analysis - Advanced code analysis

Security Metrics

Current security status:

MetricResult
Unsafe code blocks0
unwrap() in production0
panic!() in production0
Known vulnerabilities0

Vulnerability Disclosure Timeline

When a vulnerability is reported, we follow this timeline:

  1. Day 0: Acknowledge receipt of report
  2. Day 1-7: Investigate and verify vulnerability
  3. Day 7-14: Develop and test fix
  4. Day 14-21: Release patch version
  5. Day 21: Public disclosure (coordinate with reporter)

Security Hall of Fame

We appreciate security researchers who responsibly disclose vulnerabilities.

Security Contacts

References