policy
Security
A file-processing service faces untrusted uploads, hostile filenames, resource exhaustion and the usual web attacks, so the defence here is layered: every PDF is structurally validated before a byte is processed, files are stored under random names that no user input can influence, state-changing requests require a token, security headers are set on every response, and a bounded job queue means the worst case is a polite 'we are busy' rather than a collapse.
The layers
| Risk | Control |
|---|---|
| Malformed or hostile PDF | Structural validation: page count, object count, encryption, size - refused before processing |
| Path traversal via filenames | Files are named after random ids; no user string ever reaches a path |
| Cross-site request forgery | A per-session token on every state-changing POST |
| Clickjacking, MIME sniffing, referrer leaks | Content-Security-Policy, X-Frame-Options, nosniff and referrer headers on every response |
| Resource exhaustion | Upload, page, object and tile limits plus a bounded queue and a per-job timeout |
| Password exposure | PDF passwords are passed in memory for the call only - never stored, logged or returned |
| Server-side request forgery | The service never fetches remote URLs, so there is no URL-fetch surface at all |
| Log leakage | Structured logs with keys such as passwords and filenames redacted before they are written |
What we deliberately do not claim
Uploads are not virus-scanned. A PDF can carry an exploit aimed at the software that opens it, and this service is not a sandbox for hostile documents - the validation layer checks structure and size, not payloads. The practical mitigation is that files live for under an hour, are never served to other users, and are not scanned or previewed by people.
Operational security
- A signing secret is mandatory in production; the service refuses to start without one
- Rate limits on uploads, jobs, previews and downloads, per client
- A free-tier daily allowance enforced server-side, so abuse costs stay bounded
- Errors return friendly messages; stack traces and internal paths are never sent to the browser
- Optional error reporting is off unless an operator configures it
Reporting a problem
If you find a vulnerability, write to the support address in the footer with enough detail to reproduce it. Reports are acknowledged, fixed and credited; we do not pursue good-faith research.
Frequently asked questions
Are uploads scanned for malware?
No, and we say so rather than implying otherwise. The service validates PDF structure and size before processing, but it does not run an anti-virus scan. Files exist for less than an hour, are never served to other users, and are deleted on schedule.
Is the connection encrypted?
Yes in production. The service is deployed behind HTTPS, so the upload, the watermarking job and the download all travel over TLS. Local development runs over HTTP on the machine itself.
What stops someone overloading the service?
Layered limits: a maximum upload size, a maximum page count, a guard on the number of PDF objects, a cap on tiled repetitions, a per-job timeout, and a bounded queue with a small worker pool. A burst of demand produces a short wait or a clear refusal, never unbounded work.
Do you store my PDF password?
No. If a document is locked, the password you type is passed to the processing call as an argument and exists only in memory for that call. It is never written to the database, the logs or any response.