Security Architecture
Every architectural decision in F-Leaves was made with security as the primary constraint. Not performance. Not convenience. Security first, everything else second.
Six Security Pillars
Every document is encrypted with its own randomly generated 256-bit DEK (Data Encryption Key) using AES-256-GCM authenticated encryption. The DEK is then encrypted with your master KEK (Key Encryption Key). Even with full access to both the database and the file storage, documents cannot be decrypted without the master key in the server's memory.
Tenant data isolation is enforced at the PostgreSQL database engine level — not the application layer. RLS policies fire for every SELECT, INSERT, UPDATE, and DELETE. An application bug, misconfigured query, or SQL injection cannot access another tenant's data. The policy cannot be bypassed by any means available to the application role.
Every document viewed in F-Leaves receives two simultaneous watermarks. A visible diagonal overlay showing the viewer's email, timestamp, and session ID at 10% opacity. An invisible LSB steganographic watermark encoding the same identity into the least significant bits of pixel data — invisible to the eye, detectable with our decoder tool. Upload any leaked screenshot and identify exactly who viewed it.
Every action in F-Leaves is logged to an append-only audit table: who performed it, when, from which IP address, what the outcome was, and the severity level. Audit records cannot be modified or deleted — not even by administrators. The audit trail is exportable to CSV for regulatory submission and is admissible as evidence of document handling procedures.
MFA/TOTP enforced per user with 8 single-use backup codes. JWT access tokens expire after 1 hour. Refresh tokens are hashed and stored in Redis with 30-day TTL. Configurable password policy per organisation. Idle session timeout from 1-120 minutes. Rate limiting on all login endpoints. Failed login attempts logged. All sessions visible and revocable by the user.
F-Leaves is self-hosted. Your data never touches Gomaiti's servers. No telemetry. No cloud sync. No third-party analytics. Deploy on your own server, your own data centre, or a Nigerian cloud provider. You control the encryption keys. You control the data. You control who has access. Gomaiti has zero access to your platform or your documents.
Encryption Flow
Document bytes arrive at document-service
Generate random 256-bit DEK via os.urandom(32)
Encrypt bytes: AES-256-GCM(plaintext, DEK, nonce)
Store ciphertext in MinIO → S3-compatible object storage
Encrypt DEK: AES-256-GCM(DEK, MASTER_KEY, nonce)
Store encrypted DEK in PostgreSQL. Plaintext DEK discarded.
The question to ask your current vendor
"If someone obtained a copy of your entire database, could they read our documents?"
For F-Leaves, the answer is no — not without the master key in the server's environment. For most ECMS solutions, the answer is yes.
Security Checklist
Request the full security whitepaper, schedule a technical deep-dive, or ask any question about our architecture.