Secure File Uploads: Why Extension and MIME Checks Are Not Enough
Published September 2026 by Solarc Labs
Treat every uploaded file as untrusted input, even when the extension looks right
A filename ending in .pdf or .jpg is useful routing information, not proof that the bytes are a safe document or image. OWASP recommends allowing only the file extensions the business workflow actually needs, after handling the filename safely, rather than accepting arbitrary formats and trying to block a growing list of dangerous ones. The control should start from the job. If a client-document request only needs PDF, JPEG and PNG, an executable, archive or office macro format should not become acceptable merely because the browser can upload it. Narrow type support also makes later parsing, scanning, review and retention rules easier to define.
Do not trust the browser-supplied Content-Type as a security decision
The MIME or Content-Type value that arrives with an upload is client-controlled and can be spoofed. It can still be a useful quick consistency check or a way to catch accidental mistakes, but it should not be the only reason a file is accepted. Compare the declared type with the expected extension and then inspect the actual content using an appropriate parser or content-validation method. When those signals disagree, fail closed or quarantine the object for a bounded review path instead of silently choosing the most convenient label.
Magic bytes and file signatures are another signal, not a silver bullet
Checking an expected file signature can help detect obvious mismatches, but OWASP explicitly warns against using signature validation on its own. A file can contain the expected leading bytes and still be malformed, polyglot, parser-hostile or carry content that becomes dangerous in a later processing step. ASVS 5.0 V5.2.2 frames the stronger requirement as correspondence between the accepted extension and the actual content, with techniques such as magic-byte checks, image rewriting or specialised validation libraries depending on the format. The implementation therefore needs format-aware validation rather than one universal “magic bytes passed” flag.
Bound the resource before expensive parsing starts
File handling is also an availability problem. Set an explicit upload-size ceiling based on what the workflow can safely process, and consider expanded size when archives or compressed content are permitted. Limit filename length and avoid using a user-supplied name as the storage identity. Generate an application-controlled storage identifier and keep the original display name as metadata only when the business needs it. Those limits reduce accidental storage exhaustion, overwrite/path problems and unexpectedly expensive parsing while giving the user a clear supported boundary.
Separate upload, quarantine, review and release instead of making acceptance one Boolean
A safer document intake flow has explicit states. The newly received object can be stored away from the public webroot, associated with the authorised request, and kept out of ordinary staff processing until the required validation or scanning steps finish. Unsupported or suspicious material can remain quarantined or be rejected without becoming a normal downloadable object. Authentication and authorisation apply on both sides of the flow: who may submit to this request, and who may later read, replace, download or release the stored file. If files can be retrieved, serve them through an application-controlled access path rather than exposing a user-controlled filesystem path or predictable public filename.
Antivirus, sandboxing and CDR can add layers without becoming a guarantee
OWASP recommends antivirus or sandbox analysis when available and Content Disarm & Reconstruct for suitable formats such as PDF or DOCX. These controls can reduce risk, but none turns an arbitrary uploaded object into guaranteed-safe content. Scanner coverage changes, parsers have vulnerabilities, encrypted files may be opaque and external scanning services can create data-leakage or confidentiality concerns. Choose those layers from the actual threat and data model. Record what was scanned or transformed, which result was observed and what state transition it allowed. Preserve the exact submitted object when the review/evidence model requires it, rather than silently replacing evidence with a transformed copy and losing the distinction.
The upload endpoint itself still needs ordinary web security controls
File validation does not replace request security. The upload route still needs authenticated or otherwise intentionally identified users, authorisation for the target request, CSRF protection where the application model requires it, request and rate limits, least-privilege storage permissions, safe error handling and securely configured parsing libraries. The download path deserves the same attention. A file that was acceptable to store should not automatically become public, executable or renderable in a trusted application origin. Treat serving, previewing and exporting as separate operations with their own content-disposition, authorisation and isolation decisions.
Use ClientVault as a bounded request-and-review workflow, not a universal file-safety claim
ClientVault is positioned around expiring client requests, supported PDF/JPEG/PNG intake within product limits, malware scanning before normal staff processing, exact-file review and explicit accept, replace and acknowledge states. The useful boundary is the request-and-review trail: what was requested, what exact object arrived, what state it reached and what still needs a person to decide. That does not mean one extension check, MIME check, scanner result or ClientVault itself proves an arbitrary file safe. The firm still chooses the required document types, evaluates substantive sufficiency, handles exceptions and decides what can be released or relied upon.
Primary sources
Sources used for this article
Continue the job