File Uploads Are Not a Form Field: Build a Safer Upload Pipeline

A careers form accepts PDFs. A customer portal allows invoices and screenshots. The file reaches storage, the antivirus scanner reports clean, and the team considers the upload finished.

That shortcut is where risk starts. A file upload is not a form field. It is a pipeline for content fully controlled by the user. The pipeline is reliable only when acceptance, validation, processing, storage, delivery, access control, and deletion work together.

OWASP recommends defense in depth for uploads. Extensions, MIME checks, file signatures, size limits, authorization, storage location, and where appropriate malware or content inspection reinforce one another. No single control is a security verdict.

Myth 1: We only allow PDF and JPG

An allowlist is useful, but it is not sufficient. Filenames can mislead, double extensions can bypass weak filters, and the Content-Type supplied by the client can be spoofed. OWASP therefore recommends combining several signals and allowing only the types the business workflow actually requires.

A solid intake path checks at least:

• an allowed, normalized extension,
• server-side type detection,
• characteristic file signatures,
• maximum size and, where relevant, image dimensions,
• authentication and authorization of the uploader.

Complex formats may also need parser or content validation. Even signature checking is not enough on its own.

Myth 2: The browser already provides the MIME type

Multipart requests commonly include values such as image/jpeg or application/pdf. That header is useful as a plausibility check, but it is user-controlled input. OWASP explicitly notes that it is easy to spoof.

When the extension, reported MIME type, and actual content disagree, the application should not guess. Reject the file or keep it quarantined until the conflict is resolved.

Myth 3: The antivirus scanner says clean

Malware scanning is valuable, especially when employees later open uploaded documents. It cannot know every future parser vulnerability and does not decide whether a format can become active content in the browser. OWASP therefore describes a layered model rather than a single silver-bullet check.

Treat a scan result as one workflow state, not as the definition of safe.

The overlooked part: files get processed

Even when an application never directly executes an upload, it often does plenty with it:

• resize images,
• render PDFs,
• parse office documents,
• extract archives,
• read metadata,
• send content to OCR or AI services,
• generate previews.

Every parser adds attack surface. Resource exhaustion matters too: huge dimensions or highly compressed archives can consume disproportionate memory or CPU. Processing stages therefore need their own timeouts, resource limits, and explicit failure states.

Quarantine first, release later

For sensitive uploads, an explicit lifecycle is safer than writing directly into final public storage. One practical model is:

1. accepted – request and permissions passed,
2. quarantined – stored but not available through normal product access,
3. validated – type and business rules passed,
4. scanned – required malware or content inspection completed,
5. ready – the product may now use the file,
6. rejected/failed – access remains blocked and retry or cleanup is defined.

This prevents the UI from claiming success while an important background security step later fails.

Storage location is a security decision

OWASP recommends a separate host or, at minimum, storage outside the webroot. User files should not become executable application content simply because they landed in a publicly served directory.

In modern systems this often means:

• object storage or a dedicated media service,
• server-generated object keys instead of user filenames as paths,
• private buckets for private content,
• least-privilege permissions,
• authorized or time-limited download routes,
• separate permissions for upload, processing, and delivery.

A random filename is not authorization. A UUID may be hard to guess and still leak through logs, referrers, or shared links.

Delivery needs security controls too

RFC 9110 defines Content-Type as key metadata for how an HTTP representation is processed. Historical MIME sniffing can create security problems.

The WHATWG MIME Sniffing Standard explicitly highlights user-uploaded content as a sensitive case: if a server intends to deliver a low-privilege type but the browser interprets it as HTML, contributed content can become active in the browser's security context.

Protected download and preview routes should therefore use:

• the correct Content-Type,
• X-Content-Type-Options: nosniff,
• an explicit decision between inline display and download,
• authorization checks on every retrieval,
• appropriate cache rules for private files.

MDN explains that nosniff tells browsers to respect the declared MIME type rather than reinterpret the response as another type.

Size limits must constrain real processing cost

A single 20 MB limit is better than nothing, but processing can still be expensive. Depending on the product, also limit:

• request and file size,
• number of concurrent files,
• image dimensions,
• expanded archive size,
• processing time,
• user or workspace quota,
• rate limits.

These controls protect workers, bandwidth, and availability as well as storage.

An upload audit should attack assumptions

A useful test goes beyond one valid PDF. Deliberately try:

• allowed extension with unexpected content,
• allowed MIME header with a mismatched signature,
• double or unusual extensions,
• a file just beyond the size limit,
• interrupted and parallel uploads,
• scanner or parser outages,
• retrying the same upload,
• access without permission or after permission is revoked,
• direct object URLs instead of application routes,
• private files through CDN or cache,
• deletion including thumbnails and derived files.

The HTTP status is not the whole result. Inspect where the file was stored, whether it is retrievable, which background jobs still run, and whether the user sees an accurate state.

What Website-Pflichtencheck would inspect

A technical file-upload review can examine file-type policy, extension/MIME/signature validation, parsers, malware scanning, quarantine, filenames, storage permissions, size and rate limits, authentication, authorization, CSRF protection, preview and download routes, Content-Type, nosniff, cache/CDN behavior, failures, retries, retention, and deletion.

The goal is not maximum friction. It is a narrow, understandable pipeline that accepts only the files and processing the product actually needs.

If your upload security model is extension check plus antivirus, you have two useful controls. You do not yet have a secure upload pipeline.