Unrestricted file upload

An upload feature accepts files too freely, letting people host malware, overwrite data, fill storage, or make the server run uploaded code.

users can upload any fileimage upload accepts malwareuploaded script runs on the serverfile upload can overwrite thingssomeone uploaded a php file to our avatar formunrestriced file uploadrenaming an exe to jpg gets throughour uploads folder is just sitting on the web serverhow do I stop people attaching anything they want

See it

Live demo coming soon

What it is

An unrestricted file upload lets the sender control too much about what is stored: the type, size, name, destination, or whether the server later executes or serves it. The result can be malware hosting, storage exhaustion, overwritten files, active HTML served from your domain, or remote code execution when a script lands somewhere executable.

Reach for the term anywhere users attach avatars, documents, imports, archives, or support files. Allowlist the few business-required types, verify content rather than trusting Content-Type or the extension, impose size and count limits, generate the storage key yourself, and keep uploads outside the application tree on a separate non-executable origin.

A filename is not safe just because .php became .jpg. File signatures can be forged, formats can be polyglots, and even a valid image may attack the parser that opens it: ImageTragick (CVE-2016-3714) turned an ordinary ImageMagick convert call into remote code execution. Defense is layered: re-encode images, scan files with ClamAV, sandbox complex parsers, serve downloads with Content-Disposition: attachment, and authorize every later read.

Ask AI for it

Harden this file upload flow using the OWASP File Upload Cheat Sheet. Allowlist only the MIME types and extensions required by the product, verify magic bytes with the file-type package, enforce per-file and per-account size limits while streaming, and generate a random UUID storage key instead of using the supplied filename. Store files outside the application tree on a separate origin with no execute permission, scan them with ClamAV before release, and re-encode accepted images with Sharp. Serve downloads through an authorization check with Content-Disposition: attachment and X-Content-Type-Options: nosniff. Add tests for double extensions, false Content-Type headers, oversized and truncated files, HTML disguised as an image, duplicate names, and cross-tenant download attempts.

You might have meant

path traversalremote code executioninput validation and contextual output encodingleast privilegeattack surface

Go deeper