Security model

This page sums up what you need to know as a developer. The Security page describes the full model.

Envelope encryption

• Each file gets its own random 256-bit data key.
• The file's content and name are encrypted with that key using AES-256-GCM, which detects any tampering.
• The data key is itself encrypted with a master key that exists only in the service's environment, never in the database. A copy of the database contains only encrypted data.
• Each ciphertext is bound to its file's ID: a ciphertext moved to another record won't decrypt.
• View tokens and API keys are stored only as SHA-256 hashes.

What the API never returns

A source document never leaves the vault as a file, whatever key is used. For such documents, the API returns only metadata and page images watermarked with the viewer's name. Only delivery documents, which you explicitly uploaded as deliverables, can be downloaded. A stolen API key can therefore be used to create view links, which are logged and watermarked, but not to exfiltrate the originals.

The access log

Every upload, link open, page view, download, revocation and deletion is recorded with its date, the viewer's email and their IP address when known. If a screenshot circulates, the watermark shows who took it and when, and the log confirms it. To get an accurate IP address, pass the end viewer's IP in x-viewer-ip when you serve the pages from your application.

Limits, plainly stated

• The service has to decrypt a file to render its pages. Someone with administrator (root) access to the server could read the master key from memory or from the environment, and therefore the documents. Encryption protects against a leak of the database or the backups, not against a full server compromise.
• Anyone holding a valid token can read the document until it expires. Keep durations short and revoke links as soon as they are no longer needed.
• With embedded viewing, your application decides who sees what. An authorization flaw on your side exposes documents to people who shouldn't read them, though still with a watermark and an entry in the log.

To report a vulnerability, email [email protected].