File Upload Security: The Extension Is Not the File

An upload feature accepts bytes from someone else's computer and brings them into your system. Those bytes may be a legitimate document, a disguised executable, a decompression bomb, or content designed to exploit a parser. Checking that a filename ends in `.pdf` or `.jpg` is not enough. Neither the extension nor the browser-supplied content type proves what the file contains. Secure handling requires several independent boundaries. ## Restrict what the product actually needs Use an allowlist of supported formats instead of trying to recognize every dangerous file type. Apply request-size limits before buffering the entire body, and set limits on file count and per-account storage. Inspect file signatures and parse content with maintained tools where appropriate, while recognizing that no single check establishes safety. A valid image can still be extremely large after decoding. A small archive can expand into an enormous directory tree. Bound processing time, memory, dimensions, page count, and expanded size according to the format. Treat parser failures as explicit errors, not permission to accept the file without inspection. ## Keep storage separate from execution Generate storage names on the server. Preserve the original filename only as display metadata after sanitizing it. Do not concatenate untrusted path segments into local paths or allow an upload to overwrite application files. Store durable assets in appropriate object storage rather than an application's temporary filesystem. Keep private files private, and enforce authorization when issuing download access. A hard-to-guess storage key is not a substitute for access control. Quarantine files while asynchronous scanning or conversion runs. Make the pending state visible so users do not interpret unfinished inspection as a broken download. Where warranted, use malware scanning or content disarm and reconstruction as additional layers. ## Control how files are served An uploaded HTML document served under your application's origin may run scripts with privileges you did not intend. Consider a separate origin for untrusted content, restrictive response headers, and attachment downloads for formats that should not render inline. Use a server-selected content type and appropriate `Content-Disposition`. Avoid displaying raw uploaded markup inside the application. Image transformation can reduce some risks, but the transformation service itself needs resource limits and updates. Test double extensions, misleading content types, oversized decoded images, unauthorized downloads, and interrupted uploads. Add cleanup for abandoned multipart uploads and failed conversions. Upload security is not a yes-or-no file check. It is a chain of decisions about admission, processing, storage, and delivery. A weakness in any one stage can bypass careful validation in another. ## Further reading - [OWASP: File upload cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) - [MDN: Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)