Secure Upload Pipelines
Treat an uploaded file as untrusted input throughout receipt, storage, processing and delivery. Allow only needed content types, bound resource use, isolate processing, keep unreviewed objects out of normal delivery, and check authorization when a file is retrieved. A filename, MIME header or scan flag alone cannot establish that a file is safe.
Start with the business purpose and the file types it truly needs. Then define a state machine and the trusted evidence required to move an object from quarantine to an approved delivery path. Keep the upload body and any extracted text outside the application's instruction and authorization authority.
TL;DR
- Treat every uploaded file as untrusted input through receipt, storage, processing, and delivery.
- Allow only the content types the feature needs, bound sizes and processing resources, and isolate parsers and converters.
- Keep files in quarantine until trusted checks pass, and keep unreviewed objects out of normal delivery paths.
- Check authorization at retrieval on every path: downloads, previews, caches, and generated derivatives.
- A filename, MIME header, or scanner flag alone never proves a file is safe.
Quick Example
This Python function checks a fictional server-record policy. It consumes no file bytes, runs no parser or scanner, and creates no storage object or download URL. It assumes the record comes from trusted application state.
The checks reject quarantined content, another tenant and an obsolete policy marker. They show only the stated predicate. If a caller can forge the record or set approved, the predicate has no trustworthy basis. Actual state transitions, file validation, scanner results, object identity and enforcement at delivery remain untested.
Core Concepts
Validate several independent boundaries
OWASP recommends needed-type allowlists, generated storage names, size limits, authorized uploaders, storage separation and appropriate scanning or content processing. It explicitly warns that a user-supplied Content-Type is spoofable and that signature checks should not stand alone. OWASP file-upload guidance
Use that defense-in-depth approach to design actual checks. An extension describes a name, a MIME header is a client claim, and a signature recognizes part of a format. None proves that a complete document can be processed safely by the chosen library or that its content is permitted for the intended use.
Define limits beyond compressed upload size where relevant. Decompression, image dimensions, page count, parser complexity and generated output can consume more resources than the received object suggests. Choose limits and failure behavior appropriate to the supported formats and processing environment.
Quarantine is an enforced storage state
Keep unapproved objects outside the normal application delivery path. Map a generated object identity to the original metadata without trusting a user filename as a storage path. Prevent path traversal, overwrite and cross-tenant references at the actual storage boundary.
This is an editorial control/test map. Only the small fictional download predicate was executed; no actual stage implementation was assessed.
Inspection and promotion need the same object identity
Bind checks to the actual stored object version or content identity. If the file can change after scanning but before delivery, an approval record can refer to different bytes from those served. Review object immutability, replacement rules and atomic transition behavior in the chosen storage system.
Keep scanner error, timeout, unsupported format and clean result distinct. An unavailable scanner should not silently become a pass. A clean result still has a scope and engine/signature version; it does not prove the absence of every possible malicious behavior.
Processing is a separate attack surface
Document parsing, image transformation, archive extraction and preview generation can exercise complex libraries. Run only the capabilities required for that operation and review filesystem, network, credential and resource access. Keep dependencies maintained through the approved process and test how failures are contained.
Treat extracted text and metadata as data. A document can contain instructions asking a downstream agent or operator to expose secrets or approve access. Content inspection does not make those instructions authoritative. Preserve the application's own boundaries when the file enters search, summarization or automation.
Download authorization belongs at delivery
Check the caller against the actual object ownership and sharing policy when issuing or serving a download. A hard-to-guess object name is not authorization. If a signed URL is used, review its scope, lifetime, caching and revocation implications under the actual service contract.
Choose response behavior appropriate to the file and use. Inline rendering can create different risks from an attachment, and a preview can contain derived content with its own access rules. Test the actual browser and delivery infrastructure rather than assuming storage permissions cover every derivative.
Best Practices
Write one lifecycle record linking upload identity, tenant, state, checks, object version, processing outputs and access policy. Restrict who can mutate approval state. Keep sensitive document contents out of routine logs while retaining enough evidence to investigate a rejected or incorrectly delivered object.
Test negative and boundary cases in an authorized disposable pipeline. Include incorrect extensions, misleading MIME claims, malformed supported content, archive expansion limits, parser timeouts, failed scans, changed object versions and cross-tenant downloads. Use safe controlled fixtures rather than real malicious documents or private customer files for exploratory checks.
Review any external scanning destination before sending content. OWASP notes disclosure concerns around public analysis services. A security feature should not create an unapproved data transfer. The example sends nothing to a scanner or other service.
Plan cleanup, retention and retry ownership. Quarantine objects, rejected files and derived previews can persist beyond the main record if their lifecycle is unclear. Apply the actual data and retention requirements with the responsible owners; do not make blanket deletion decisions from a generic tutorial.
Reverse an approval or delivery decision when trusted inspection evidence is absent, stale, for another object version, or outside the permitted format. Reduce supported types when safe processing and review are not available. The easiest parser to secure is sometimes the one the product does not need to invoke.
Common Mistakes
Trusting the MIME type or extension
Storing uploads under caller-controlled paths
Treating a scanner timeout as clean
Testing only upload authorization
FAQ
Did the example scan a file?
No. It tested a fictional state/access policy only. Byte validation, parsing, malware scanning, object promotion and actual downloads remain separate implementation tests.
Is a clean scan sufficient?
No single check establishes complete safety. Keep type/resource validation, isolation, version identity and authorization around the scan, and preserve its documented limitations.
Why authorize downloads again?
The caller and sharing state can differ from upload time. Enforce the actual current policy at the delivery boundary rather than relying on knowledge of a URL or filename.