File Upload Vulnerabilities and How to Secure Uploads

Profile pictures, documents, CSV imports, attachments: almost every product accepts files. Each upload feature is a door into your infrastructure, and attackers know it.

What can go wrong

• Web shells. An attacker uploads a script, such as shell.php, into a directory the server executes. Visiting it gives remote code execution.
• Stored XSS. An uploaded HTML or SVG file served from your domain runs JavaScript in visitors' browsers.
• XXE. SVG, DOCX and XLSX files contain XML that an unsafe parser may process.
• Path traversal. A filename like ../../config.js overwrites files outside the upload directory.
• Denial of service. Huge files, decompression bombs or images with enormous dimensions exhaust memory and disk.
• Malware distribution. Your domain hosts malicious files for others.
• Parser exploits. Vulnerabilities in image or document processing libraries triggered by crafted files.

Validation that does not work

• Checking only the extension. shell.php.jpg, shell.pHp and other tricks bypass naive checks.
• Trusting the Content-Type header. The client sets it, so attackers can set it to anything.
• Client-side validation only. Attackers skip the browser entirely.

A secure upload checklist

1. Store files outside the web root, ideally in object storage such as S3, never in a directory the application server executes.
2. Generate random filenames and keep the original name only as metadata.
3. Allowlist file types and verify by inspecting file content, not just the extension.
4. Set size limits on the request and on processed output, such as image dimensions.
5. Serve user files from a separate domain, for example usercontent.example.net, so any script runs in a different origin from your app.
6. Set safe response headers: Content-Disposition: attachment for downloads, a correct Content-Type, and X-Content-Type-Options: nosniff.
7. Re-encode images to strip metadata and embedded payloads.
8. Process files in isolation, in a sandboxed worker with no access to internal networks.
9. Scan for malware if users share files with each other.
10. Use pre-signed URLs with short expiry for direct uploads to and downloads from object storage, scoped to the right user.

Access control on uploaded files

Uploads often contain sensitive documents. Make sure download URLs are not guessable and are checked for authorisation. Public bucket URLs or sequential IDs can expose every customer's files.

Testing upload features

Effective testing tries executable extensions, polyglot files, SVG with scripts, XML payloads, oversized files and path manipulation in filenames, then checks how and where files are served. SecurityInfinity agents test upload endpoints and verify impact safely. Try the free PHP2Shell scanner for PHP upload risks, or start free.

Frequently asked questions

Are image uploads safe?

Not automatically. SVGs can contain scripts and XML, and crafted images can exploit processing libraries. Re-encode raster images and treat SVG carefully.

Should uploads be scanned for viruses?

Yes, if files are shared between users or downloaded by staff. It reduces the risk of your platform spreading malware.

Is S3 storage secure by default?

New buckets block public access by default, but misconfigured policies and pre-signed URLs with long expiry still cause exposures.