What are file upload vulnerabilities?

A file upload vulnerability allows files to be uploaded or processed without sufficient control over their type, content, name, size or later use. Consequences range from stored XSS to full code execution on the server.

Why are file uploads dangerous?

An uploaded file passes through several systems: web server, application, malware scanner, image or document library, object storage, CDN and finally another user's browser. Each component interprets names, metadata and content differently. Something that appears to be an image during upload may be served as HTML or treated as executable code by the server.

Which attacks are possible?

Why are extension and MIME type insufficient?

Both are supplied by the client or easily manipulated. Double extensions, capitalization, alternative suffixes and server configuration bypass simple blocklists. Magic bytes improve identification but do not prove that the whole file is harmless; polyglot files can be valid in several formats. An allowlist and safe downstream handling need to work together.

How are uploads processed securely?

• Permit only file types, sizes and quantities required by the business function.
• Determine type from content and parser results, not client headers.
• Generate random server-side names; never reuse client names as paths.
• Store outside the web root or in isolated object storage without execution rights.
• Serve with fixed Content-Type, Content-Disposition and X-Content-Type-Options: nosniff.
• Authorize every download and keep temporary URLs short-lived.
• Use malware scanning, quarantine, limits and monitoring as extra layers.

Code example: upload handling in Laravel

Vulnerable: The original name and public storage are trusted.

$file = $request->file('document');
$file->move(public_path('uploads'), $file->getClientOriginalName());

Safer foundation:

$validated = $request->validate([
    'document' => [
        'required',
        'file',
        'mimes:pdf',
        'max:5120',
    ],
]);

$path = $validated['document']->store('documents', 'private');

$document = $request->user()->documents()->create([
    'storage_key' => $path,
    'original_name' => $validated['document']->getClientOriginalName(),
]);

The private disk must not be executable or directly public. Authorized delivery, malware scanning and safe PDF processing remain separate layers.

What about images and documents?

Images should be fully decoded and re-encoded with a maintained library. This removes much external data but not every parser vulnerability. SVG is active XML content and needs special handling. Office and PDF files can contain macros, links, embedded objects and personal metadata. Archives require limits on file count, paths, nesting and total expanded size.

How are upload functions tested?

Testers vary extension, MIME type, signature, filename and size independently. They inspect alternative endpoints, chunking, imports, archives and later delivery. The key questions are whether content can execute, be read by another user, replace unauthorized files or exhaust parsers. Proofs use harmless markers instead of functional malware.