Validating, storing and serving user file uploads

Goal

Let users upload documents or images without giving them a way to run code on the server, plant scripts that execute in other users' browsers, or fill the disk.

Prerequisites

A list of file types the feature actually needs; a storage location the web server does not execute from; a size budget per file and per user.

Steps

1. Require authentication for uploads and rate-limit them per user.
2. Validate the extension after decoding the filename against an allowlist of the required types only; the OWASP cheat sheet (cited) names double extensions (.jpg.php) and null bytes (.php%00.jpg) as bypasses of naive filters and calls blocklists weak on their own.
3. Check the content: the cheat sheet states that the client's Content-Type cannot be trusted; verify the file signature (magic bytes) against the expected type and, for images, re-encode through an image library so embedded payloads are destroyed. Reject archives unless the feature is about archives, and then extract with path checks and a post-decompression size limit.
4. Discard the user's filename for storage; save under a random identifier (a UUID) and keep the original name as metadata, length-limited and character-restricted, for display only.
5. Enforce the size limit at the web server and in the application; count decompressed size where files are processed.
6. Store outside the web root, or on a separate host, with least-privilege filesystem permissions and no execute bit; the cheat sheet ranks a different host first, then outside the web root.
7. Serve through an application handler that maps the identifier to the file, checks authorization, sets Content-Type from your own record (never from the file), X-Content-Type-Options: nosniff, and Content-Disposition: attachment; filename="..." (MDN, cited) unless inline display is required for a type known to be inert.
8. Where inline display is needed (images, PDFs), serve from a separate origin with a restrictive Content Security Policy, so that a file that turns out to be HTML or SVG with script cannot act on the main origin's cookies.
9. Scan with an antivirus or hash-reputation service if the files are re-distributed, and give users a way to report content.

Expected result

An uploaded .php, .html or polyglot file is stored as an opaque blob under a random name, never executed, and delivered as a download or from an isolated origin.

Limits and test basis

Follows the cited sources; no measurement claimed. Signature checks are bypassable on their own and are one layer among several. SVG and PDF can carry script and need the separate-origin treatment or conversion. Storing files in the database is possible but shifts the load and backup problem there.

The download filename comes from the validated type

The original filename is metadata, and its extension must not reach the Content-Disposition header unchanged: the extension in that header decides what the recipient's operating system does with the file, and a name such as report.pdf.exe or invoice.html stored at upload time is executed or rendered locally after download, where nosniff no longer applies. Build the served name from your own record: keep the user's base name only if it passes a character allowlist and a length limit, append the canonical extension for the validated type, and encode the header per RFC 6266 (filename*=UTF-8''... for non-ASCII, with quotes and control characters removed). Test with an upload whose original name carries a double extension and confirm the download arrives under the chosen one.