Local ownership, not authorization
The process lock enforces one owner of a directory. It does not authenticate application users, authorize records, or make a collection a tenant boundary.
Keep the raw DB handle behind application services that validate identity and permissions. Use separate directories/accounts when independent local ownership is required. Apply OS access controls to the files and any backups.
Files are unencrypted
Keys, values, WAL contents, tables, and metadata are not encrypted by the engine. A tombstone or compaction is not a secure-erasure guarantee for underlying storage, backups, or filesystem history.
If local data requires encryption, use an appropriate platform/storage layer and validate its behavior with your application. Do not describe ZeeDB as providing end-to-end encryption, key management, encrypted replication, or audited cryptography.
Checksums are not authentication
CRC32 detects accidental corruption. It does not prevent deliberate replacement by someone who can alter database files and recompute checksums.
Treat external file access as part of the application’s deployment threat model. The engine’s checksum parser is not an authorization mechanism or a hostile multi-user storage boundary.
Payload validation belongs to the application
The engine checks key/collection structure and configured sizes. It does not validate document fields, sanitize values for HTML rendering, or enforce application relationships.
Decode JSON carefully, reject unsupported application schemas, and avoid trusting an unvalidated value just because a storage read succeeded. ZeeDB’s HTTP server validates its wire format and full-access token, not your application schema or end-user permissions. Those remain your backend’s responsibility.
Logging and diagnostics
Keys, collection names, and record contents can all contain sensitive information. Prefer operation names, durations, error classes, counts, and redacted identifiers over raw payloads.
Bug reports and benchmark datasets should not contain credentials or personal application data. Keep recovery copies under the same access policy as originals.
Server authentication and transport
zeedb serve provides a bearer-authenticated HTTP API with optional TLS, request bounds, and localhost binding by default. See the server guide. The token grants full access to all collections and administrative operations. Keep it in trusted backends. Direct browser requests with Origin headers are rejected; no CORS is enabled.
There is no multi-tenant authorization, per-user quota, device registration, sync permission enforcement, encryption at rest, or security audit. Use HTTPS and network controls online. Refer to the scope and roadmap when describing capabilities to application users.