A framework for thinking about file upload attack classes
File upload functionality remains one of the highest-value targets in web application security, because a successful attack can hand the attacker code execution directly rather than just data access. This note organises the main attack classes conceptually, without describing or endorsing any particular tool.
Extension and content-type spoofing
The most basic class of attack tries to get an executable file accepted by disguising its type: appending a trusted extension, manipulating the declared content-type header, or using double extensions that some server configurations parse differently than expected. Defences here rely on validating the file's actual content rather than trusting any client-supplied label, and on using an explicit allow-list of permitted types rather than a deny-list of forbidden ones.
Path and filename manipulation
A second class targets where the file ends up rather than what it contains, using directory traversal sequences or crafted filenames to write outside the intended upload directory, potentially overwriting an existing file. Defences include stripping or rejecting path separators from filenames, generating a new random filename on the server rather than trusting the client-supplied one, and storing uploads in a directory the application controls strictly.
Content-based attacks that survive validation
A third class accepts a file whose extension and declared type are legitimate but whose content is crafted to be interpreted differently by a downstream consumer than the upload validator expected, such as a polyglot file that is simultaneously valid as an image and as script in some execution contexts. Defences here include re-encoding or stripping metadata from uploaded media server-side, and serving uploaded content from a separate origin with no script execution permissions.
Execution-context attacks
The most severe class results in direct code execution: an uploaded file lands somewhere the web server will execute it as a script. This is less about the upload mechanism itself and more about hosting configuration, and the most reliable defence is architectural, storing uploads on infrastructure, such as object storage, that has no script execution capability at all, rather than trying to filter every dangerous extension by name.
Takeaway for builders
No single check closes every class above. A resilient upload pipeline layers content validation, strict path handling, and execution-incapable storage, so that a gap in any one layer does not translate directly into compromise.
Key takeaways
- Extension and content-type checks must validate actual file content, not client-supplied labels.
- Filename and path handling needs server-generated names and strict directory controls to stop traversal.
- Polyglot-style files can pass validation and still be dangerous in a different execution context.
- Serving uploads from execution-incapable storage is the most reliable defence against the worst-case outcome.
This note has been rewritten and checked for this edition; it is not a copy of the original post.