Safe Document Previews: Isolating SVG, PDF, and Office Active Content

A document preview is a processing and delivery path for untrusted input. SVG can contain scripts and references, PDFs can contain actions and attachments, and Office files can contain macros, embedded objects, or external links. Storing the file as a business record does not make its contents safe to execute in the application’s browser context.

Design the preview path around separate decisions: whether the file may be stored, whether processing may begin, which rendition may be displayed, and whether the caller may retrieve the original. A clean malware result answers only part of that design.

FormKiQ’s point of view: preserve the original, control the representation

Keep the original document and its provenance while giving ordinary reviewers the least active representation that supports their task. A page image or sanitized text view can be appropriate for routine review; an original download needs its own permission and handling. Connect every rendition to the exact source version, processing result, and release policy.

FormKiQ’s Anti-Malware / Antivirus module provides ClamAV scanning and scan-result metadata through document-event processing. Configure workflow ordering so a required scan finishes with an acceptable result before preview conversion or release. Scanning, converter isolation, rendition authorization, and browser delivery are distinct controls to verify in the chosen deployment; enabling a scanner does not automatically establish all four.

Choose the preview path for the format and context

SVG behavior depends on how it is embedded. The W3C’s SVG security notes distinguish image use, where scripts are disabled, from document embedding. A thumbnail rendered through an image element does not establish that the same uploaded SVG is safe when opened directly or through a different viewer.

Validate the file without trusting its label

Allow the business formats the system supports, then compare the submitted name and content type with detected content and structural parsing. A file signature is one signal, not proof that every parser will interpret the file the same way. Handle mismatches and ambiguous formats explicitly rather than letting the browser choose how to execute them.

Apply size, page-count, image-dimension, archive-expansion, nesting, and processing-time limits. The OWASP File Upload Cheat Sheet recommends layered validation and scanning rather than reliance on a single check. Use safe generated storage identifiers and keep untrusted filenames from controlling paths or response headers.

Make scan status an enforced workflow gate

Keep pending, rejected, and unscannable files out of ordinary previews, search thumbnails, and downstream conversion. A scan-completed event is not equivalent to a clean result. Check the result, permitted processing state, source version, and relevant policy before progressing. Define what happens when the scanner is unavailable, times out, or cannot inspect an encrypted file.

Bind the scan and converter input to the same captured bytes. If a user replaces the source, the earlier scan and rendition must not authorize the new version. Keep the source identifier, version or checksum, detected type, scan engine and definitions, timestamp, and result with the processing record.

A scan that finds no known malware does not certify that active document features are acceptable. A legitimate script, link, or macro may still violate the preview policy. Keep isolation and rendering restrictions in place for clean files.

Isolate the converter as well as the browser

A converter parses attacker-controlled structures before the browser sees a rendition. Run it with narrowly scoped access to the assigned input and output, no application session credentials, a restricted filesystem, bounded resources, timeouts, and disposable working storage. If a runtime requires an execution identity, scope it to the job instead of giving it broad document-administration privileges.

Block unnecessary outbound network access, including external document resources and access to internal services or instance metadata. Disable macros, remote templates, external entities, and linked-content retrieval where relevant. Enforce these restrictions at the runtime or network boundary as well as through converter options.

Record converter and configuration versions, patch the processing stack, and validate that outputs match the expected rendition format. Conversion failure should produce a controlled review state. It must not silently switch the preview to the original file or rerun the job with broader permissions.

Give untrusted content its own browser boundary

Serve potentially active content away from the application’s privileged origin. Verify that the content host receives no application session cookies or bearer tokens; a sibling hostname is insufficient if cookies are scoped to a shared parent domain. Restrict cross-origin access to application APIs and preserve the normal server-side authorization and request-forgery controls. CORS is not a replacement for authorization.

Apply a restrictive Content Security Policy to the response that actually serves the untrusted document, not only to the parent application page. Configure permitted embedding parents and sandbox permissions for the selected viewer. Blocking all framing would also break an intentionally embedded preview, so test the policy with the intended delivery path.

The MDN iframe reference warns against combining allow-scripts and allow-same-origin for content served from the parent’s origin. Keep sandbox permissions minimal and test direct navigation as well as embedding. A viewer that requires additional capabilities needs an explicit isolation design rather than copied sandbox flags.

For SVG sanitization, use a maintained implementation with an explicit supported subset instead of string replacement. For PDFs and Office files, verify how the chosen tool handles actions, embedded files, links, and external resources. A conversion to PDF does not by itself establish that the output is inert.

Authorize each rendition and original separately

Check the caller’s current access to the document, source version, and requested representation before issuing a retrieval grant. Preview permission need not include the original, embedded attachments, or bulk export. Apply the same rules to thumbnails, search results, sharing routes, and cached artifacts.

Use validated content types, suitable Content-Disposition, and X-Content-Type-Options: nosniff for the delivery path. Configure caching so one user’s authorized response cannot become another user’s accessible preview. Protect signed retrieval URLs from logs and referrer leakage, and define the remaining access window after a grant is withdrawn.

An attachment response is a delivery instruction, not a guarantee that the file is safe when opened on a recipient’s device. Keep original downloads explicit, with policy-appropriate handling and evidence. For redacted or restricted renditions, verify that alternate routes cannot expose the unredacted original or hidden content.

Worked example: a clean SVG with disallowed active features

1. 1. Accept into restricted processing

   A supplier uploads an SVG containing script and external references. Capture version V-12 and its checksum. The malware scan reports no known malware; the file remains subject to the active-content policy.

2. 2. Create the permitted rendition

   An isolated worker processes the captured version with script execution disabled and external fetching blocked and produces an approved raster rendition. Record the converter version, result, and source-to-rendition mapping.

3. 3. Serve the preview through the controlled path

   An authorized reviewer receives the generated image. A direct request for the original SVG is evaluated separately and cannot inherit the application’s browser privileges.

4. 4. Handle an unsupported replacement

   A later version fails validation or conversion. Keep it in a review state instead of serving the original inline or relabeling V-12’s rendition as a preview of the replacement.

Verify every path with a controlled regression corpus

• Use approved fixtures with SVG scripts and external references, PDF actions and attachments, and Office macros or remote links. Verify the intended features cannot execute or fetch resources through the preview path.
• Test malformed, oversized, encrypted, and mislabeled files. Verify scanning or conversion failure cannot trigger a permissive fallback.
• Exercise upload, thumbnails, search previews, direct URLs, sharing, exports, and original downloads using supported browsers and viewer versions.
• Test cross-user access, changed source versions, expired grants, cached responses, and direct navigation to the content host. Confirm that application credentials remain isolated.

Keep known-safe business files in the corpus too, including accessibility and rendering requirements. Monitor failed scans, converter crashes, blocked outbound requests, resource-limit violations, and outdated renditions. Reprocessing after an incident or tool update should preserve provenance and update the permitted delivery state.