Security

secure-docs stops the people you share with from taking a document away, and makes any leak traceable back to them. It doesn't make a leak impossible. This page says exactly what is protected and what isn't.

We don't hold any security certification (ISO 27001, SOC 2 or similar). If your work requires one, check this before trusting us with documents.

Threat model

For each risk: what we do, and where it stops.

The recipient downloads the document
Protection
They never receive the file, only page images rendered for them. Original uploads can't be downloaded at all, not even through the API.
Limit
Only files you upload as deliverables can be downloaded.
The recipient prints, copies the text or saves the page
Protection
Printing, selecting, copying and right-clicking are blocked in the viewer.
Limit
A technical user can still pull the page images out of the browser. They carry the same watermark as a screenshot.
The recipient takes a screenshot or photographs the screen
Protection
Every page carries their name, email, the date, the time and their IP address, repeated diagonally across the page and in a band at the foot. The page blurs when the window loses focus.
Limit
No website can prevent a screenshot. The protection is traceability: the copy names the person who made it.
The link is forwarded to someone else
Protection
The watermark shows the intended reader's name, not the new person's. Every opening is logged with its IP address. Links expire, and you can revoke them.
Limit
While a link is valid, anyone holding it can open it. Treat it like a password.
The database leaks
Protection
Files and their names are encrypted with AES-256-GCM, one key per file. The master key is not stored in the database.
Limit
A copy of the database alone isn't enough to read any document.
Someone gets root access to the server
Protection
The master key is kept apart from the data, in the service's environment rather than the database.
Limit
Someone with root on the server can read the master key and decrypt documents. This risk is not covered.
An API key is stolen
Protection
Keys belong to one account and can be revoked from the dashboard at any time. Original uploads still can't be downloaded with a key.
Limit
With a valid key, an attacker can upload files and create view links. Keep keys on your server.

Threats, protections and limits
Threat	Protection	Limit
The recipient downloads the document	They never receive the file, only page images rendered for them. Original uploads can't be downloaded at all, not even through the API.	Only files you upload as deliverables can be downloaded.
The recipient prints, copies the text or saves the page	Printing, selecting, copying and right-clicking are blocked in the viewer.	A technical user can still pull the page images out of the browser. They carry the same watermark as a screenshot.
The recipient takes a screenshot or photographs the screen	Every page carries their name, email, the date, the time and their IP address, repeated diagonally across the page and in a band at the foot. The page blurs when the window loses focus.	No website can prevent a screenshot. The protection is traceability: the copy names the person who made it.
The link is forwarded to someone else	The watermark shows the intended reader's name, not the new person's. Every opening is logged with its IP address. Links expire, and you can revoke them.	While a link is valid, anyone holding it can open it. Treat it like a password.
The database leaks	Files and their names are encrypted with AES-256-GCM, one key per file. The master key is not stored in the database.	A copy of the database alone isn't enough to read any document.
Someone gets root access to the server	The master key is kept apart from the data, in the service's environment rather than the database.	Someone with root on the server can read the master key and decrypt documents. This risk is not covered.
An API key is stolen	Keys belong to one account and can be revoked from the dashboard at any time. Original uploads still can't be downloaded with a key.	With a valid key, an attacker can upload files and create view links. Keep keys on your server.

Encryption

Each file is encrypted with AES-256-GCM under its own key, generated at upload.
File names are encrypted the same way.
Each file key is itself encrypted by a master key that lives only in the service's environment, never in the database. A copy of the database holds nothing but ciphertext.
GCM authenticates the content: a tampered file is refused when decrypted.
Every encryption is bound to the file's id, so ciphertext moved to another record won't decrypt.
Decryption happens on the server, at the moment a page image is rendered.

What gets logged

Upload: The document and the time it arrived.
Link opened: The intended reader, the date, the time and the IP address.
Page shown: Every page displayed, with the reader, the time and the IP address.
Download: Every download of a deliverable.
Revocation: The revoked link, the reader it was for, and the time.
Deletion: The deleted document and the time.

Every plan can read the log in the dashboard. Business can export it as CSV.

Hosting

Documents, the database and the service run in Germany, in the European Union, on Hetzner servers.

Deletion

When you delete a document, its ciphertext is erased and every view link to it stops working. Its entries stay in the activity log, so you keep the record of who read it.

Two limits you should know about

Screenshots

No website can block a screenshot, a screen recording or a photo taken with a phone, and secure-docs doesn't claim to. What we guarantee is that every image shown carries the reader's identity, so a copy that circulates points at them. The protection is traceability, and the deterrence that comes with it.

Root access to the server

The server needs the master key to render pages, so someone with root access to it could read the key and decrypt documents. This is not end-to-end encryption.

Found a vulnerability, or have a question this page doesn't answer? Write to [email protected]. For integration details, see the documentation.

Security

Threat model

The recipient downloads the document

The recipient prints, copies the text or saves the page

The recipient takes a screenshot or photographs the screen

The link is forwarded to someone else

The database leaks

Someone gets root access to the server