Security
How Cloak protects the values you store, from the database up to the moment a value reaches your running process.
Envelope-style encryption, one master key
Every secret value is encrypted with AES-256-GCM before it ever reaches Firestore. The encryption key is a random 32-byte value you generate yourself and store as a server-only environment variable — never in the database, never sent to the browser.
Ciphertext at rest, always
The database stores ciphertext, a nonce (iv), and an auth tag — never a plaintext value. A safe preview (e.g. sk_live_...9f2a) is computed once and stored separately for identification in the dashboard.
Decryption only through server routes
Reads are served by an API route that checks membership (for the dashboard) or a machine token's scope (for the CLI), then decrypts — the client never receives ciphertext to decrypt itself.
Scoped machine tokens
A token is minted for exactly one project and environment, with Read or Read/Write access and an optional expiry. Tokens are looked up by a SHA-256 hash of the raw value, stored in a collection no client can ever read — only server routes, via the Admin SDK.
Full audit trail
Every read and write, by a person or a token, is recorded with actor, action, target, and timestamp — written exclusively by server routes, so there's no path for a client to forge or skip an entry.
What actually happens on write
When you run cloak secrets set KEY=value or edit a secret in the dashboard, here's the exact path the value takes:
1. Request arrives at a server route (never the browser)
2. Route verifies who's asking:
- dashboard → Firebase Auth session, checked against workspace membership
- CLI/CI → machine token, hashed and looked up server-side
3. Value is encrypted: AES-256-GCM with the master key
4. { ciphertext, iv, authTag } is written to Firestore as a new version
5. A safe preview (first 8 + last 4 chars) is stored for the dashboard list
6. One audit log entry is writtenWhat's stored where
Readable by workspace members
- • Secret key names and safe previews
- • Project, environment, and token metadata
- • Audit log entries
Never readable by any client
- • Ciphertext, nonces, and auth tags
- • Machine token hashes
- • The master encryption key itself
On the master key vs. a hardware-backed KMS
Cloak's encryption key currently lives as a server-only environment variable rather than in a managed key service like Cloud KMS. That trades away automatic key rotation and hardware-backed storage in exchange for zero infrastructure cost — a reasonable choice early on, and one you can revisit once it matters for your team.
Reporting a vulnerability
Found an issue? Email usecloak.co@gmail.com with details. We aim to acknowledge reports within one business day.