File Upload Security: Testing the Pipeline End to End

Short answer

File upload security is not complete after an extension check or antivirus scan. A safe pipeline protects authorization, size and type validation, parser isolation, private storage, download behavior, and the way asynchronous scan results affect application state. Uploading a file must not make it trusted or public by default.

An upload feature moves data across the web app, parsers, object storage, CDN, preview services, and background workers. The attack surface includes not only the upload endpoint, but also where content is rendered and who can retrieve it later.

Validate type and content

Content-Type, filename, and extension are controlled by the client. Define an explicit allowlist based on business need. Validate filenames after URL decoding and Unicode normalization; test double extensions, null bytes, case changes, and path separators. File signatures or magic bytes are useful additional signals, but do not prove that content is safe.

Validate the format that downstream parsers actually process. Image conversion, PDF extraction, office previews, and archive expansion invoke different parsers. A malformed but plausible file can consume excessive CPU or memory. Set type-specific limits for pixel count, pages, archive entries, compression ratio, nested archive depth, and processing time in addition to byte size.

Assign an application-generated random storage key. Do not use the client filename as a filesystem path, and encode it safely in response headers. Store files outside the webroot or on a separate storage host. Reapply identity and object authorization on every download.

Scanning and state transitions

If antivirus, sandboxing, or Content Disarm and Reconstruction (CDR) is used, model how it connects to the upload transaction. Files should move through explicit states such as pending scan, clean, rejected, or scan error. Treating a file as clean when the scanner is unavailable is a fail-open path. A user should not access a preview before scanning by changing an object ID or requesting it early.

For an asynchronous pipeline, verify that the queue message, storage key, and tenant context refer to the same object. Processing the same file twice should be idempotent; a deleted or rejected file must not become public after a retry. If scanning sends customer content to an external service, define a clear data-handling policy for that transfer.

Stage	Security control
Upload request	User and tenant authorized; size and quota bounded
Temporary storage	Not public; unpredictable key
Parser/scanner	Isolated resources, timeout, and format limits
Preview	Clean status and resource ownership verified
Download	Authorization checked each time; safe content disposition
Deletion	Storage, caches, thumbnails, and derivatives removed

Downloads, active content, and cache

User uploads served as HTML, SVG, PDF, or office documents from the same origin can create stored XSS or active-content risk. Consider serving files from a separate origin that does not carry application credentials, with safe Content-Disposition and X-Content-Type-Options behavior. If inline preview is needed, transform active content or render it from a sandboxed origin.

A CDN cache key based only on filename can mix downloads across tenants. Define the lifetime, sharing scope, and revocation behavior of private file URLs. If a URL leaks into logs or a referrer, how long does it still provide access?

Test and retest plan

Document allowed formats, maximum sizes, scan states, and download roles.
Test spoofed MIME types, double extensions, wrong signatures, malformed files, and size boundaries safely.
Try Tenant A’s file as Tenant B across preview, download, and deletion operations.
Exercise scanner outages, queue retries, duplicate workers, delayed results, and deletion.
Review separate-origin behavior, caching, and response headers.
Prove that no derivative remains accessible after a file is rejected or deleted.

Presigned URL ve resumable upload sınırları

Object storage’a doğrudan yükleme için presigned URL kullanılıyorsa imzanın yalnızca hedef bucket’ı değil, izin verilen yöntem, nesne anahtarı, boyut ve geçerlilik süresini de kısıtlayıp kısıtlamadığını inceleyin. URL’nin başka kullanıcı adına tekrar kullanılabildiğini, upload tamamlanmadan nesnenin okunabildiğini ve metadata/content-type değerlerinin sonradan değiştirilebildiğini test edin. Multipart veya resumable upload akışlarında parça sayısı, toplam boyut, tamamlanmamış upload’ların yaşam süresi ve abandon edilen parçaların temizlenmesi için sınır olmalıdır.

Dosya karantinası ile yayımlama arasında atomik bir geçiş tasarlayın. Scan sonucu geldiğinde nesne aynı storage key ve checksum ile eşleşmeli; dosya tarama sonrasında değiştirilemiyor olmalıdır. Böylece taranan içerik ile kullanıcının sonradan indireceği içerik farklılaşmaz.

For an assessment of upload flows across web and API boundaries, see our web application security testing service.