Safe file-upload pipelines: a document is not trusted knowledge

A model to inspect

Upload to grounded answer

01Quarantine bytes
02Validate and extract
03Apply access policy
04Index approved text
05Retire derivatives

A successful parser is not a trust decision.

Original conceptual diagram · not a live trace or measured result.

Start with an intake boundary

An upload is a byte stream plus untrusted claims about its name, type, and origin. Give it an immutable upload ID, authenticated owner and tenant, received time, declared purpose, size, and a temporary quarantine location. Do not place it in the same public path used for downloadable results. The initial response should say that processing is pending; it must not imply the file has been read successfully.

OWASP recommends allowlisting extensions, validating file type independently of the Content-Type header, changing stored names, and keeping files outside the webroot where possible. Those are controls at intake, not a declaration that a format is harmless. A PDF can be a useful document and still be an unsafe parser input or an inappropriate source for another user.

Define a type and size policy

Allow only formats the service actually supports. Check extension, detected signature or magic bytes, declared media type, file size, page or archive-entry limits, and whether the format is encrypted or contains unsupported embedded material. Reject ambiguous files with a clear user-safe reason. A generic “upload anything” promise creates pressure to run unknown content through whatever parser happens to be installed.

Worked example, hypothetical: a support bot accepts PDF and DOCX up to the team’s documented threshold, but rejects password-protected archives and macro-enabled formats because the service has no approved path for them. It does not rename an executable to .pdf and hope an extension check holds. The artifact record states why processing was declined and does not expose scanner details.

Quarantine before extraction

Run malware scanning and type inspection before a specialized extractor, and run extraction in an isolated, resource-bounded environment. Treat OCR output, document properties, hyperlinks, embedded text, and table cells as untrusted content too. Limit CPU time, memory, recursion, decompressed size, and pages processed; record timeout or extraction failure as a processing state rather than silently indexing a partial result.

A scanner verdict is a point-in-time signal, not source approval. Likewise, a successful extractor only says it produced bytes. Separate the original object from derived text, thumbnails, and chunks so a later deletion, rescanning decision, or policy change can locate every derivative.

Authorize before knowledge assembly

Use the owner, tenant, sharing grant, classification, and lifecycle state when deciding whether extracted text can enter an index. The extracted text needs a parent upload ID and the same access restrictions as the original, plus a status such as quarantined, approved, failed, revoked, or deleted. Do not put a file in the global semantic index and rely on a prompt to avoid it later.

Counterexample: an employee uploads a draft contract to ask for a summary. If the extractor immediately chunks it into a shared collection, the bot may later retrieve its title or clause for another employee. The correct service path keeps it private by default and exposes it only under an explicit, current grant.

Make extraction limitations visible

Document extraction can lose page order, columns, footnotes, charts, visual labels, and access constraints. A response should identify the upload and section when it relies on derived text, and should say when the system could not verify a visual claim. Never state that a scanned signature, map coordinate, or spreadsheet formula was read correctly merely because text extraction returned something.

Offer a review route for high-impact use. A service operator can inspect the original in a controlled viewer, compare it with the extracted segment, correct access metadata, or remove the upload. This is a workflow recommendation, not an assertion that every upload needs a human reviewer.

Exercise deletion and failure paths

Test mismatched type headers, oversized archives, malicious-looking samples handled under safe test procedures, extractor crash, partial text, revoked share, deleted original, and a user querying while processing remains pending. Assert that no derived item is retrievable before approval; that deletion removes or tombstones all defined derivatives; and that the user receives truthful status. Keep test fixtures synthetic or authorized.

Success criteria: each upload has a lifecycle record; every derived chunk links to its parent; only allowlisted and completed paths can become searchable; and a reviewer can answer where a claimed passage came from. OWASP guidance identifies defensive techniques, but your retention, scanning provider, and acceptable formats are local risk decisions.

Take it into the review

Upload lifecycle register

Stage	Allowed state	Required record	Exit
receive	quarantined	owner, size, detected type	reject or scan
extract	approved for processing	extractor version, limits	derive or fail
index	share verified	parent ID, policy version	retrievable
revoke	access removed	invalidation evidence	exclude
delete	tombstoned	derivative cleanup	not found

A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.

Primary reading

Sources and limits

These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.

What the sources establish

File Upload Cheat Sheet

OWASP recommends measures including extension allowlists, independent type validation, generated filenames, storage outside the webroot, and scanning.

Limits: This is general security guidance and does not certify an extractor, scanner, or document format.

Checked 2026-09-19 · OWASP · source publication date not established.

Open original source ↗

Input Validation Cheat Sheet

OWASP describes input validation as an early control and distinguishes syntactic from semantic validation.

Limits: It does not define a file-retrieval lifecycle or access model.