security
What protects your documents, in specifics you can check.
report a vulnerability
Found something? Tell us first.
Write to us with the details and, if you can, the steps to reproduce it.
- who reads it
- A person on the team
- credit
- If you would like it
Follow a document through Mezdoc.
From the upload to the webhook, this is the control at each stop.
Upload
Straight to storage
PDF uploads go directly to object storage through a short-lived signed URL, not through our application servers.
Storage
Encrypted at rest
Documents and templates live in encrypted object storage and application data in a managed application database, both encrypted at rest. Every connection uses TLS.
Every request
Checked against the owner
A request for a template, submission or file is checked against the account that owns it before anything comes back.
Rendering
Escaped, and kept inside
Your data is escaped before it reaches the page. The renderer loads only your own stored images or inline data, and loops are bounded so a hostile payload cannot exhaust it.
Delivery
A link that lasts one hour
A finished PDF goes out through a signed link tied to that one document, which expires after an hour. The storage URL is never exposed.
Webhooks
Signed, and never pointed inward
Deliveries to endpoints you configure are HMAC-signed over the timestamp and body. URLs that resolve to private, loopback or link-local addresses are refused when saved and again at every delivery, and redirects are not followed.
Controls in place today.
- Encrypted at rest
- Files and database
- TLS in transit
- Every connection
- Ownership checks
- On every request
- Hashed API keys
- Shown once, stored as SHA-256
- Keys per environment
- Each renders only its own
- Signed downloads
- One document, one hour
- Signed webhooks
- HMAC over timestamp and body
- Append-only audit log
- Publishes, links, runs
- Pinned versions
- Re-render identically
- Origin-locked embeds
- Closed until you list an origin
- Email code limits
- 10 minutes, 5 tries
- Password hashing
- scrypt, 12 characters minimum
Keys and sign-in
- API keys are 256-bit random tokens. We store only a SHA-256 hash and compare in constant time, so a database dump does not yield a usable key.
- The raw key is shown once, when you create it. Nobody can recover it later, including us.
- Each key belongs to one environment and renders only the version published there.
- Passwords are hashed with scrypt and need at least 12 characters. Sessions are httpOnly cookies that expire after 7 days.
Links you share
- A link can expire after 7, 30 or 90 days and carry a maximum number of uses. Each use is claimed atomically, so simultaneous submissions cannot slip past the limit.
- An optional email code: six digits, valid for 10 minutes, and burned after 5 wrong tries.
- An embedded form loads only on the origins you list for that link. With none listed, it refuses to load in a frame.
- Revoke a link and it stops accepting submissions and stops loading in frames.
A record you can check later.
When a question comes up months later, the answer is already written down: which version, which file, who submitted it and when.
- Every publish freezes a snapshot, including the exact source PDF, so a document made months ago re-renders the same today.
- Each submission keeps the time, IP address, device, template version and a SHA-256 of the PDF that anyone can recompute, plus the email when an email code was used.
- A workflow run adds a certificate of completion as its own PDF.
- The audit log records publishes, restores, link creation and revocation, and every run. Entries are only ever added.
- Webhook deliveries are logged with their status and attempt count.
- Outside production, every render carries the environment name as a watermark, so a test document is never mistaken for a real one.
Privacy and compliance, straight answers.
- Do you sign a data processing agreement?
Tell us what your review needs through the contact page, and we will tell you plainly what we can agree to. We answer security questionnaires in writing.
- Can we put protected health information in Mezdoc?
No. Mezdoc is built for insurance paperwork, not medical records. Please keep protected health information (PHI) out of Mezdoc: we do not sign business associate agreements.
- Do you sell our data or train models on our documents?
No. We collect only what the product needs, never sell your data, and never train models on your documents.
- Can we export or delete our data?
Yes. Ask for an export or deletion at any time and we will action it, following GDPR and CCPA principles.
Read the privacy policy- Where is our data stored?
Documents and templates are kept in encrypted object storage, and application data in a managed application database. Both are encrypted at rest, and every connection is encrypted in transit.
- How do we report a vulnerability?
Write to us through the contact page with the details and, if you can, the steps to reproduce it. A person on the team reads every report and replies by email, and we credit you if you would like us to.
Report it through the contact page