📄PDFik Docs

Security

How PDFik treats your documents, your credentials, and the untrusted content it renders. Everything on this page describes mechanisms that are actually deployed — nothing aspirational.

Automatic document deletion

  • A generated PDF is downloadable for 24 hours after the job finishes; after that the API answers 410 file-expired.
  • Physical deletion is enforced by a storage lifecycle rule — objects are purged within 48 hours of creation, worst case.
  • The document bucket has no versioning and no backups. Nothing is archived; an expired document is gone.
  • Objects are encrypted at rest with server-side encryption (SSE, AES-256, AWS-managed keys). Note what this does and does not mean: it protects the storage medium, and access is restricted to the rendering pipeline's IAM roles — but it is not client-side encryption. If your threat model requires that no infrastructure operator can ever access a document, encrypt content before sending it and treat PDFik as a transport.

The durable production pattern is to fetch each finished file once into your own storage — see the Quickstart.

The renderer

The rendering fleet assumes every URL and every byte of HTML is hostile:

  • Chromium runs WITH its sandbox. No --no-sandbox flag anywhere: unprivileged user namespaces plus a default seccomp profile. Most rendering services disable the sandbox for convenience; we did the work to keep it.
  • One BrowserContext per job, torn down in a finally block. Jobs never share cookies, storage, or page state; downloads are disabled and popups are closed automatically.
  • Network interception at render time. Every request the page makes — including redirects and subresources — is re-validated before it leaves the renderer. Blocked: private ranges, loopback, link-local, carrier-grade NAT (100.64.0.0/10), cloud metadata endpoints, file:// and every non-HTTP(S) scheme. Submit-time URL validation alone is not enough (a redirect can reach 169.254.169.254 after validation passes) — so the check runs where the traffic happens.
  • Network policies at the cluster level back this up: rendering pods can reach the database, the queue, and the public internet — nothing else.

Credentials

  • API keys are stored as SHA-256 hashes. The plaintext exists only in your hands; it is never stored or logged.
  • Per-job credentials (the auth option for authenticated rendering) are encrypted with AES-256-GCM before they enter the queue. The queue, the dead-letter queue and admin tooling all see ciphertext only; the worker decrypts immediately before the render and attaches the credential only to same-origin requests.
  • Webhook signing secrets and custom delivery headers are stored AES-256-GCM encrypted.
  • Webhook deliveries are signed (X-PDFik-Signature, HMAC-SHA256 over a timestamped payload) and the destination URL is re-validated against the same SSRF rules on every attempt, with redirects disabled.
  • Account security: optional TOTP two-factor authentication on dashboard login, and per-key IP allowlists for API access.

Data location & deletion requests

  • All processing and storage run on AWS in the United States. An EU processing region is on the roadmap but is not available today — if EU-only processing is a hard requirement, we are not the right fit yet, and we would rather tell you that here than in a sales call. The exact region is named in the DPA and Privacy Policy, where data-transfer disclosure is legally required.
  • Deletion on request: a deletion request marks the account immediately and is processed manually within 30 days, as described in the DPA and Privacy Policy. Generated documents are already gone within 48 hours regardless.
  • Invoices and billing records are retained as required by accounting law — see the Terms.

Reporting a vulnerability

Found something? Write to [email protected] with SECURITY in the subject. We read every report, respond to real findings, and will credit you if you want credit. Please give us reasonable time to fix before publishing.