← All docs

Security & Output Safety

A PDF is an untrusted document: it can carry hostile URIs, scripts, and adversarial content streams. DynDyn.Pdf turns such a document into HTML that is safe to open in a browser and safe to serve to third parties. This page documents the output-safety posture, the resource-abuse surface, and a deployment hardening checklist.

1. Output-safety posture

Live, selectable text — never a screenshot

Text is emitted as real, positioned HTML (<span>/semantic elements) drawn with subset web fonts synthesized from the PDF's own glyph outlines. The document stays machine-readable and accessible — this is a hard constraint for regulated output such as ESEF filings. Even when a page's graphics are rasterized for correct compositing (--background raster or raster fallback), the text layer stays live HTML on top of the raster.

Every dynamic string is HTML-encoded

All text pulled from the PDF is passed through WebUtility.HtmlEncode before it enters the output — run text, the document title, bookmark/TOC labels, link labels, and link href/title attributes. A <script> (or any markup) sitting in the source text becomes inert, encoded characters. Verified in code: text runs (HtmlPageComposer), titles/labels (ViewerOutputWriter, MultiPageOutputWriter, HtmlTemplates), and link attributes (HtmlPageComposer.AppendLinks).

Link URI whitelist — hostile schemes can't reach the HTML

Clickable link annotations are extracted, but their targets are filtered at extraction time (ManagedExtractionEngine.IsSafeExternalUri) before any URI is written:

• External URIs survive only if the scheme is http://, https://, mailto:, or tel:. A javascript: or data: URI (the classic PDF→HTML XSS vector) is dropped, as is file: (which can't work in portable HTML and would leak the author's local paths).
• Internal navigation is honored only for GoToAction (same-document page jumps). Remote-file (GoToRAction) and embedded-file (GoToEAction) go-to actions are not followed.
• Anything with no resolvable, safe target is skipped entirely — no element is emitted.

Surviving external links are rendered with target="_blank" rel="noopener noreferrer" and their URI is additionally HTML-encoded, so even a whitelisted URL can't break out of the attribute.

Self-contained, no external references

single/viewer output inlines fonts, images, and SVG as data: URIs. There are no outbound references in the artifact — no remote fonts, trackers, or beacons — so opening the HTML leaks nothing and works offline. This makes a strict Content-Security-Policy trivial to apply.

Fonts are validated, and untrusted font bytes are contained

Synthesized fonts run through FontValidator; a font that fails is surfaced as a ConversionWarning and embedded raw so browsers' OpenType Sanitizer (OTS) can reject/fall back gracefully. No font failure aborts the document or injects markup.

Warnings never leak into the page

ConversionWarnings are logged and returned on ConversionResult — never embedded in the output HTML — so diagnostic text (which may echo document content) can't become an injection channel.

Recommended Content-Security-Policy

Because the output is fully self-contained, serve it under a tight CSP. A single-file artifact needs inline styles and data URIs but no scripts; the viewer app needs inline script for navigation:

# single / per-page / multi-page output (no scripts needed)
Content-Security-Policy:
  default-src 'none';
  img-src 'self' data:;
  font-src data:;
  style-src 'unsafe-inline';
  base-uri 'none';
  form-action 'none';

# viewer output (adds inline navigation script)
Content-Security-Policy:
  default-src 'none';
  img-src 'self' data:;
  font-src data:;
  style-src 'unsafe-inline';
  script-src 'unsafe-inline';
  base-uri 'none';
  form-action 'none';

Adjust img-src/font-src if you host assets externally rather than inlining. The whitelist above already guarantees any surviving href is http(s)/mailto/tel, so navigation is safe under default-src 'none'.

2. Resource budgets & abuse surface

Conversion is CPU-bound and memory scales with page complexity and DPI. A hostile or pathological PDF (huge page count, enormous images, deeply nested XObjects) is a denial-of-service surface. Current built-in bounds:

The defaults in the first column are pinned by SecurityE2eTests.Defaults_MatchDocumentedBudgets.

Not yet enforced in-process: a total output-size cap. Everything else above is on by default or one option away; still impose the outer limits externally, because a budget only bounds what the converter meant to do:

• Container CPU/memory limits — the primary DoS backstop.
• Reverse-proxy upload cap lower than 1 GB for your real workload.
• Request timeout / concurrency limit at the gateway, in addition to ConversionTimeoutSeconds and MaxLiveJobs.
• An external reaper on %TEMP%/dyndyn-pdf-web as a backstop for the in-process one: a pod that dies mid-job leaves its upload and partial result behind until the next run. Wipe by age, or mount the temp dir as tmpfs and recycle the pod.

3. Deployment hardening checklist

Network & access

• /api/* is gated by API-key middleware (DynDynPdf:ApiKeys / AllowAnonymous, see api.md); the default with no keys configured only serves loopback callers. Configure keys (or AllowAnonymous=true behind your own gateway auth) before exposing /api/* to untrusted networks.
• Job ids are not secrets; the per-job ownership token returned once by POST /api/jobs is what gates events/download/preview and the cancelling DELETE (403 without a matching token). This matters most for AllowAnonymous=true/open deployments where many callers share one key or none — don't log the token or forward it to anything besides the caller. See api.md.
• Terminate TLS at the proxy; the app speaks plain HTTP by design.
• Cap upload size at the proxy below the 1 GB app limit for your workload.
• Apply request timeouts and a concurrency limit at the gateway.

Process & container

• Run as a non-root user (the sample Dockerfile does).
• Read-only root filesystem with a writable /tmp only (the service writes job scratch there).
• Drop all Linux capabilities — the app needs none.
• Set CPU and memory limits (primary DoS backstop until budgets ship).
• Mount the job scratch dir as tmpfs / emptyDir and recycle it, or run an external reaper.

Data handling

• Treat %TEMP%/dyndyn-pdf-web/<jobId> as sensitive — it holds the raw upload and result. Wipe on job completion or on a schedule.
• For sovereignty/regulated use, restrict egress at the network layer (conversion makes no outbound calls of its own) and rely on the self-contained output for downstream distribution.
• Use Deterministic = true when you need byte-reproducible, auditable output.

Serving converted HTML

• Serve output under the CSP above (default-src 'none' + data URIs; add script-src 'unsafe-inline' only for the viewer).
• Prefer serving from a separate origin/subdomain so inline styles/scripts in converted documents can't touch your application's cookies or storage.
• Keep rel="noopener noreferrer" on external links (already emitted).

Build & supply chain

• TreatWarningsAsErrors=true and RestorePackagesWithLockFile=true are on — keep the lock files committed and restore with --locked-mode in CI.
• Pin/patch the native rendering library via DYNDYN_PDF_NATIVE_LIB if you must vet the native binary; otherwise it is auto-restored from NuGet per RID (no manual install).

4. Reporting

For the current build, the item to track before exposing the service publicly is a total output-size cap (see configuration.md). Page, model, time and image budgets, job expiry and the live-job cap are enforced in-process today (section 2). Authentication is implemented today (API-key middleware, see api.md); everything in section 1 (output safety) is enforced today, on every conversion, regardless of caller. Section 5 lists which of these claims an end-to-end test actually proves.

5. Verified by — test coverage map

Each guarantee above maps to the end-to-end test that exercises it through a public surface (DocumentConverter API with the managed engine, the CLI in-process, or the Web service under WebApplicationFactory). "e2e" means the assertion is made on the emitted HTML, the exit code, or the HTTP response — never on an internal helper. Guarantees with no such test are listed explicitly below the table.

Resource budgets are mapped row by row in the section 2 table.

Untested (no end-to-end test exercises the claim):

• MaxPagePixels raster clamp — unit-tested in ConversionLimitsTests; an e2e proof needs the native rasterizer (tests/DynDyn.Tests.Native).
• Web-service DPI clamp (18–600) — only the CLI's argument validation is covered.
• Kestrel request-body cap (1 GB) — only the multipart path returns 413 under TestServer.
• MaxLiveJobs admission refusal and JobTtlMinutes job expiry.
• Bounded per-document parallelism (jobs × per-doc ≤ cores) — unit only.
• Batch failure isolation in BatchConverter.
• GoToRAction / GoToEAction are not followed — no crafted document exercises them.
• FontValidator failure path (warning raised, font embedded raw, no markup injected).
• "Warnings never leak into the page" — no test feeds a warning message through and asserts it is absent from the HTML.
• CLI exit codes 4 (NativeUnavailable) and 5 (FidelityGateFailed) — need the native engine absent/present respectively.
• CSP as an HTTP response header — by design the service does not set one; it is the reverse proxy's job. The <meta> tag in the body is what the tests check.

Running the suite

# fast security tests (Integration, excluding the corpus fuzz run — seconds)
dotnet test tests/DynDyn.Tests.Integration --filter "Category!=Fuzz"

# whole fuzz corpus (about 15 min at 4-way parallelism); DYNDYN_FUZZ_LIMIT=<n> caps the file count,
# DYNDYN_UPDATE_SNAPSHOTS=1 regenerates Snapshots/Fuzz/fuzz_distribution.txt
dotnet test tests/DynDyn.Tests.Integration --filter "Category=Fuzz"

dotnet test tests/DynDyn.Tests.Cli
dotnet test tests/DynDyn.Tests.Web      # needs the .NET 10 ASP.NET runtime; the tests self-skip without it