Untrusted active content
An uploaded file is untrusted input with a name, declared media type, detected format, structure, metadata, compression behavior, and possible active content. A file can exploit a parser, escape its storage path, overwrite another object, consume resources, execute when served, or carry sensitive data to another user.
Intake and identity
Authenticate the uploader and authorize the purpose, object, tenant, size, count, and rate. Generate a server-side object identifier and storage name. Keep the original name as display metadata only after suitable length and character handling. Do not use it as a path.
Allow only formats required by the feature. Check extension, declared media type, detected signature, and successful parse, but do not assume one check proves safety. Apply size limits before buffering and decompression. Reject archive entries that escape the extraction root, create links or devices, nest excessively, or expand beyond a fixed budget.
Transform, store, and serve
Where practical, decode and re-encode images, documents, or media with a maintained library. Strip unnecessary metadata. Run parsing and scanning in an isolated worker with no application secrets, no broad network access, and strict CPU, memory, file, and time limits.
Store uploads outside executable and application directories. Keep quarantine separate from approved content. Serve untrusted content from a separate origin or as a forced download with an explicit media type, nosniff, safe disposition, and suitable content policy. Apply object authorization at download time.
Failure and residual risk
Antivirus cannot prove a file is harmless. File signatures can be ambiguous or polyglot. A parser can have its own vulnerability. A clean file can contain privacy-sensitive metadata or unsafe formulas and links. A public URL can bypass later authorization. A delayed scanner can race with serving unless state transitions are explicit.
Pomerium boundary
Pomerium can protect upload and download routes and provide caller identity. It does not inspect file structure, isolate parsers, select storage names, or enforce per-object download permission. The application must own the complete file lifecycle and prevent direct access to storage around the protected route.
Evaluation checklist
- Is upload authority bound to purpose, tenant, object, count, rate, and size?
- Are server-generated storage names independent from user-provided file names and paths?
- Which parsers, scanners, converters, and metadata handlers process the file, and with what authority?
- Can an archive escape, create a link, or exceed an expansion budget?
- Is untrusted content served from a safe origin and with explicit download or rendering policy?
- Can any direct storage URL bypass object authorization or quarantine state?
