Intake
Security
How documents are stored, who can reach them, and how to report a problem.
Client documents are the entire point of this product, so this page is specific rather than reassuring.
How files are stored
- Every upload is written with private visibility, on a local disk or an S3-compatible bucket. Nothing is ever addressable by public URL.
- The filename on disk is a UUID. The name you gave it is kept in the database for display only, so a guessed path finds nothing.
- Files are namespaced by workspace and request, so a misconfiguration cannot make one workspace's folder resolve inside another's.
- Every download goes through a signed, short-lived link, and the application re-checks authorization when the link is used. A valid signature belonging to the wrong person still gets a 403.
Workspace isolation
Every workspace-owned record carries a workspace id, and a global query scope applies it automatically once a workspace has been identified from the hostname. Attempting to read across that boundary returns nothing rather than someone else's data. This is covered by automated tests that deliberately try to cross it.
Signatures
A signed submission produces a PDF audit record containing the signature, the typed name, the exact time, the IP address, and a SHA-256 digest of the whole submission including each file's own checksum. Changing any byte of any document changes the digest, so the record is tamper-evident.
Portal links
A portal link is a credential. It can be rotated at any time, which kills the old link immediately and emails the client a new one. Links expire on a schedule the operator sets, measured from when the link was issued.
Reporting a vulnerability
Write to the address in the footer with enough detail to reproduce the issue. Please do not test against a workspace you do not own, and give us a reasonable window to fix it before publishing. We will confirm receipt and tell you what we are doing about it.