How to Handle File Uploads Securely

Client-side validation (JavaScript file type checks or HTML accept attributes) is trivially bypassed. Every upload must be validated on the server using multiple independent signals. Relying solely on the file extension or the browser-supplied MIME type is insufficient — attackers can manipulate both.

• Read the first several bytes of the file (magic bytes / file signature) and compare them against a whitelist of permitted formats (e.g., PNG starts with \x89PNG, PDF with %PDF).
• Verify the server-detected MIME type independently of the Content-Type header sent by the client.
• Maintain a strict whitelist of allowed extensions (e.g., .jpg, .png, .pdf) — deny anything not on the list rather than trying to block known bad extensions.
• Reject files with double extensions such as evil.php.jpg by stripping and validating each extension component.
• For image uploads, re-encode the image server-side (e.g., using ImageMagick or Pillow) to strip embedded payloads and confirm it is a valid image.

Unrestricted upload sizes allow attackers to exhaust disk space or memory, causing denial-of-service conditions. Setting limits at multiple layers ensures requests are rejected before they consume significant resources.

• Set a maximum file size appropriate to your use case (e.g., 5 MB for profile photos, 50 MB for documents) and enforce it in both your web server configuration and application code.
• Configure client_max_body_size (Nginx) or LimitRequestBody (Apache) to reject oversized requests at the server level before they reach your application.
• Limit the number of files that can be uploaded in a single request and the number of uploads per user per time window (rate limiting).
• Return a clear error message when limits are exceeded — do not silently truncate files, as this can lead to corrupt stored data.

Allowing user-controlled filenames introduces path traversal, overwrite attacks, and executable naming tricks. Always replace the original filename with one you fully control.

• Generate a cryptographically random filename (e.g., a UUID or a securely random hex string) for every uploaded file — never use the original filename on disk.
• Append only the validated, whitelisted extension determined by your server-side type check, not the extension from the original filename.
• If you must preserve the original filename for display purposes, store it separately in your database, not as the actual filename on disk.
• Sanitise any metadata that will be stored alongside the file (e.g., strip EXIF data from images to avoid leaking GPS coordinates or device information).

If uploaded files are stored inside a publicly accessible directory, an attacker who uploads a web shell can access it directly via URL and execute arbitrary commands. Moving storage outside the web root is one of the most effective mitigations.

• Store uploaded files in a directory that is not served directly by your web server (e.g., /var/uploads/ rather than /var/www/html/uploads/).
• Serve uploaded files through an application-controlled endpoint that reads the file from the private directory and streams it to the client with appropriate headers.
• Consider using object storage (e.g., AWS S3, Google Cloud Storage) with private bucket policies and pre-signed URLs for time-limited, authenticated access.
• Never grant write access to directories that are already served as static content by your web server.

Even if files are stored in a web-accessible directory, you can significantly reduce risk by ensuring the web server will never execute files in that directory as scripts — regardless of their extension.

• Nginx: Add a location block for your upload directory that sets default_type application/octet-stream and removes any fastcgi_pass or uwsgi_pass directives.
• Apache: Add an .htaccess file to the upload directory containing Options -ExecCGI, AddHandler default-handler .php .py .pl .rb, and php_flag engine off.
• Ensure your web server configuration does not have a catch-all handler that executes arbitrary file types as scripts.
• Disable server-side includes (SSI) for directories containing uploaded content.

Even files that pass type validation may contain embedded malicious payloads targeting downstream users (e.g., macro-enabled Office documents, polyglot files). Integrating malware scanning adds a critical second line of defence.

• Integrate a server-side antivirus solution (e.g., ClamAV) into your upload pipeline — scan files before they are committed to permanent storage.
• For high-risk environments, use a sandboxed analysis service that detonates files in an isolated environment to detect zero-day threats.
• Quarantine any file that fails a malware scan and alert your security team immediately — do not silently discard it without investigation.
• Keep virus definitions and scanning engines updated automatically so new threats are caught promptly.
• Re-scan stored files periodically in case definitions improve and detect previously undetected threats in your archive.

How files are delivered to users matters as much as how they are stored. Incorrect headers or same-origin serving can lead to Cross-Site Scripting (XSS) or Content Sniffing attacks where a browser misinterprets a file's type and executes it.

• Set the Content-Disposition: attachment; filename="safename.ext" header for all user-uploaded files to force a download dialogue rather than in-browser rendering where appropriate.
• Set an explicit, correct Content-Type header based on your server-side validated type — never reflect the client-supplied Content-Type.
• Add X-Content-Type-Options: nosniff to all responses serving uploaded files to prevent browsers from MIME-sniffing the content type.
• Serve user-uploaded content from a separate, sandboxed domain or subdomain (e.g., uploads.yourdomain.com or a CDN domain) so that any malicious content cannot access cookies or storage from your main application origin.
• Apply a restrictive Content-Security-Policy header on pages that display or link to uploaded content.

Upload functionality should never be open to the public unless your application explicitly requires it. Even where uploads are public, access to the resulting files should be gated appropriately to prevent unauthorised data access or abuse.

• Require authentication for all upload endpoints — unauthenticated upload endpoints are a common target for abuse and spam.
• Implement authorisation checks so that a user can only access files they are permitted to view — use indirect references (e.g., a UUID mapped in your database) rather than exposing the real storage path.
• Apply role-based access control (RBAC) to restrict which user roles can upload files and which file types each role is permitted to upload.
• Invalidate or expire access tokens or pre-signed URLs promptly to limit the exposure window for shared file links.
• Audit who has access to the raw storage location (cloud bucket, file server) and apply the principle of least privilege — application service accounts should have only the access they need.

Logging upload events creates an audit trail for incident response and enables anomaly detection. Without visibility into upload behaviour, attacks may go unnoticed until significant damage is done. Sensagraph continuously monitors your web application endpoints for anomalous or suspicious behaviours that may indicate upload-related attacks.

• Log every upload attempt — including the authenticated user, timestamp, original filename, detected MIME type, file size, and outcome (accepted/rejected).
• Alert on repeated upload failures from the same IP address or user account, which may indicate probing or fuzzing.
• Set up alerts for uploads of unusual file types, especially any that are close to executable formats.
• Monitor storage directories for unexpected new files, particularly those with executable extensions, using file integrity monitoring (FIM) tools.
• Review upload logs regularly as part of your routine security operations — look for patterns such as bulk uploads or off-hours activity.
• Integrate upload event logs into your SIEM or centralised logging platform so they can be correlated with other security events.

Security controls degrade over time as code changes, dependencies are updated, and configurations drift. Regular, structured testing ensures your upload controls remain effective against evolving attack techniques.

• Include upload security tests in your CI/CD pipeline — automate checks for missing headers, missing type validation, and unprotected endpoints.
• Perform manual penetration testing of upload functionality at least annually or after any significant feature change, attempting common bypass techniques such as double extensions, null bytes, and polyglot files.
• Use Sensagraph to continuously scan your application for misconfigured upload endpoints and missing security headers on file-serving responses.
• Review and update your file type whitelist periodically to account for newly supported formats or deprecated ones that should be removed.
• Conduct code reviews specifically focused on upload-handling code before merging changes to ensure new vulnerabilities are not introduced.