Security
Defense in depth, end to end.
Security is not a feature bolted onto FiscalDB — it is the reason the engine exists. From the wire to the disk, every layer assumes the data must survive an audit.
JWT authentication
Every REST and gRPC endpoint requires a signed JWT. Tokens are short-lived and carry tenant scope, so a leaked credential is bounded in time and blast radius.
RBAC with persistent grant store
Role-based access control backed by a persistent grant store. Permissions are evaluated server-side on every call — never trusted from the client.
HMAC-SHA256 signed webhooks
Outbound webhooks are signed with HMAC-SHA256 (X-FiscalDB-Signature: sha256=…), the same convention used by GitHub and Stripe, so receivers can verify authenticity.
SSRF protection on dispatch
Webhook destinations are resolved and filtered before connection. Private IP ranges and loopback are blocked at DNS resolution, closing the classic SSRF vector.
mTLS to every fiscal authority
Mutual TLS to all authorities and access points. TLS 1.2 minimum, built on rustls — no OpenSSL in the trust path.
AES-256-GCM at rest
Authenticated encryption on both the WAL and segments. Tampering with ciphertext is detected on read, not silently served.
Per-tenant cryptographic isolation
Each tenant has its own hash chain and key derivation. There is no shared mutable surface between tenants at any layer of the engine.
Tamper detection via chain replay
fiscaldb verify-chain replays the per-tenant SHA-256 hash chain and verifies every RFC 3161 token. Any byte-level modification halts verification.
Append-only semantics
UPDATE and DELETE are physically impossible at the storage layer. Corrections and cancellations are appended as new events — the record of what happened is never rewritten.