Skip to content

Sawabona Security Overview

Version: 2.0 Last Updated: 2026-01-28 Architecture: Single-Tenant Rust with Plugin-Based Payment Providers

This document describes the current security posture of the Sawabona License Server as implemented in Rust.

Stack and Dependencies

  • Framework: Actix-web (async Rust web framework)
  • Database: SQLx with PostgreSQL (compile-time checked queries)
  • Authentication: JWT via jsonwebtoken
  • Password Hashing: Argon2 via argon2
  • Rate Limiting: Built-in middleware
  • Crypto & Geometry: nalgebra, aes-gcm, sha2, hmac
  • Async Runtime: Tokio

All dependencies are managed in sawabona/Cargo.toml.

Application Hardening

HTTP Security

  • Security headers: Applied by Actix-web middleware (HSTS, X-Content-Type-Options, X-Frame-Options, etc.).
  • CORS: Configurable via environment variables and applied by Actix-web middleware.
  • Body size limits: Enforced by Actix-web request size limits.
  • HTTPS: Enforced in production via reverse proxy (Nginx recommended).

Rate Limiting

  • Implemented with Actix-web middleware.
  • License validation endpoints: 10 req/min per IP
  • Admin endpoints: 100 req/min per API key
  • Usage tracking: 1000 req/min per license

Authentication & Authorization

  • Admin APIs use an admin API key via X-API-Key header (loaded from environment).
  • License validation returns a short-lived JWT token for usage tracking calls.
  • JWT secrets are loaded from environment/config, not hard-coded.

Data Protection

  • Passwords and secrets are hashed using Argon2.
  • Database access uses SQLx with compile-time checked parameterized queries.
  • Environmental configuration (DB URLs, API keys, JWT secrets) is read from environment variables or .env files.
  • Encryption at Rest: All sensitive data (payment API keys, webhook secrets) is encrypted using AES-256-GCM.
  • Database-Level Encryption: PostgreSQL should be configured with TDE (AES-256-CBC).
  • Audit Logging: All encryption/decryption operations are logged with timestamps and action types.
  • Client-verifiable entitlements (PROPOSED): see ENTITLEMENT-SIGNING-ED25519.md — an Ed25519-signed entitlement envelope so SDKs can verify plan/features offline against a build-time-pinned public key (closes audit findings C1/C2). Today the validation JWT is HS256, so SDK clients trust the server over TLS only.

Payment Provider Security

  • API Key Encryption: Payment provider API keys are encrypted at rest using AES-256-GCM before storage in database.
  • Webhook Verification: All incoming webhooks are verified using HMAC-SHA256 signatures.
  • Provider Isolation: Each payment provider runs in its own crate with isolated dependencies.
  • Secrets Rotation: Support for rotating payment provider API keys without downtime.

License Revocation Pipeline

Sawabona uses a three-layer revocation check during license validation:

  1. Bloom filter (in-memory, O(1)) — loaded from revoked_keys table on startup. No false negatives.
  2. Redis cache — revoked:{license_id} keys with configurable TTL (default 1 hour).
  3. DB tombstone — revoked_keys table stores SHA-256 hashes of revoked key strings (append-only, never deleted).

The license row's status field is also set to revoked. Devices bound to the revoked license remain in the DB for audit purposes but cannot validate.

Device Binding & Fingerprinting

License validation binds licenses to physical devices:

  • Fingerprint: SHA-256 hash of hardware identity (machine-id, CPU, hostname, kernel version)
  • Activation limits: Configurable per-license max_activations (enforced via SELECT ... FOR UPDATE to prevent race conditions)
  • Re-validation: Existing devices are recognized and don't consume additional activation slots
  • License portability: A device with a revoked license can activate on a new license (binding is per-license, not global)

Telemetry & Attack Detection

Sawabona includes security monitoring capabilities:

  • License Validation Monitoring: Tracks validation patterns for anomalies.
  • Webhook Verification: All payment webhooks are verified before processing.
  • Rate Limiting: Protects against brute force and DoS attacks.
  • Structured Logging: All security events are logged with timestamps and context.

Important:

  • Treat security monitoring as a defence-in-depth feature, not a replacement for standard security controls.
  • Deploy behind a WAF/DDoS protection layer in production.

Areas That Are Out of Scope in This Repo

The following security-sensitive capabilities are not implemented in this repository and must be provided by your own infrastructure:

  • WAF / DDoS protection in front of the API.
  • Centralized log aggregation and SIEM rules.
  • Secret management (Vault, AWS Secrets Manager, Azure Key Vault, etc.).
  • Certificate management and HTTPS termination (reverse proxy / ingress controller).
  • Multi-tenancy isolation (this is a single-tenant architecture).

Single-Tenant Architecture

Sawabona is designed as a single-tenant, self-hosted application:

  • Each deployment serves a single organization
  • No tenant isolation overhead
  • Simplified security model
  • All data belongs to the single tenant
  • Payment providers are configured per deployment
  • Run the Sawabona server behind a reverse proxy with HTTPS enforced.
  • Store secrets (DB passwords, JWT keys, admin API keys) in a secret manager, not in source control.
  • Enable database backups and test restores regularly.
  • Monitor authentication failures, rate-limit breaches, and attack detector alerts.
  • Keep dependencies up to date following pyproject.toml constraints.