Security

Native processing without a shell

Server-side PDF processing (e.g. for “Protect PDF” or “Unlock PDF”) runs through directly spawned native processes, never through a shell. This structurally prevents command injection via a crafted filename or option.

Job access control

Every processing job is bound to the session that created it. Retrieving its status, downloading its result, or deleting it requires that same session — a guessed or otherwise known job ID alone is not enough.

Upload file validation

Uploaded files are checked against the expected file type on receipt; files that don't match the expected PDF format are rejected before processing.

Password handling

A password entered for “Protect PDF” or “Unlock PDF” is never stored as plaintext in the processing queue — it's replaced with a single-use reference before the job is enqueued.

Encrypted connections (HTTPS)

converterfleet.com, app.converterfleet.com, and api.converterfleet.com are served exclusively over HTTPS with automatically managed, auto-renewing certificates.

Container isolation

Gateway, worker, and the public website each run as a non-root process inside their container, without access to the host's Docker socket and without privileged mode.

Further container hardening (e.g. read-only filesystems, additional capability restrictions) has not been implemented yet.

Automated security checks

Every code change goes through automated checks before release: a scan for accidentally committed credentials, a license and vulnerability check of every software component used, generation of a complete software bill of materials (SBOM), and a static check for risky shell invocations in the code.