Skip to main content

Securing File Uploads: Content Type Validation–A defense against malicious files

File upload functionality is a common feature in web applications, but it's also one of the most common attack vectors. A recent security review of our applications revealed some vulnerabilities in our file upload handling that needed our attention. This is the first post in a series where I'll share how we systematically secured our file upload functionality.

The problem

The fundamental issue with file uploads is trust. When users upload files, we're essentially allowing them to store content on our servers. Without proper validation, attackers can:

  • Upload malicious scripts disguised as innocent files
  • Bypass security controls by manipulating file extensions
  • Execute server-side code through crafted payloads
  • Consume excessive server resources with oversized files

The first line of defense? Content type validation.

Our approach: A validation pipeline

Rather than implementing ad-hoc validation checks scattered throughout our codebase, we designed a clean, extensible validation pipeline. This approach allows us to:

  • Add new validation steps easily
  • Maintain consistent validation logic across the application
  • Test each validation step independently
  • Fail fast when any validation step fails

Here's the core structure:

Content type validation: The first gate

Content type validation is our first checkpoint. It ensures that only files with approved MIME types can enter our system. Here's our implementation:

These are the key design decisions we took while developing this feature:

1. Explicit allow-list

We use a SupportedContentTypes configuration that explicitly defines which MIME types are allowed. This is much safer than trying to block known dangerous types, as new attack vectors emerge constantly.

2. Case-insensitive comparison

MIME types are compared using StringComparison.OrdinalIgnoreCase to handle variations in casing that might be used to bypass naive string matching. A way to easy mistake that we made too much before…

3. Comprehensive logging

Every validation failure is logged with context. This helps with debugging legitimate upload failures and provides audit trails for potential security incidents.

4. Null safety

The code explicitly checks for null or empty content types, which can occur with malformed requests or certain browser behaviors. Nothing extra-ordinary, but we like to stay of the safe side.

The complete pipeline

The content type validation step fits in a broader validation pipeline:

Why content type validation isn't enough

It's crucial to understand that content type validation is not a complete solution. The Content-Type header is controlled by the client and can be easily spoofed. An attacker could upload a malicious PHP script but set the content type to image/jpeg.

Content type validation provides our first layer of defense, but as mentioned, it's not sufficient on its own. In the next posts, we'll dive into:

  • File signature validation: Verifying files are actually what they claim to be
  • File size limits: Preventing resource exhaustion attacks
  • Malware scanning: The final safety net against malicious content
  • Storage security: Safe handling of uploaded files

Stay tuned for the next post where we'll explore file signature validation and how to detect files that lie about their true format.

More information

Media types (MIME types) - HTTP | MDN

Popular posts from this blog

.NET 8–Keyed/Named Services

A feature that a lot of IoC container libraries support but that was missing in the default DI container provided by Microsoft is the support for Keyed or Named Services. This feature allows you to register the same type multiple times using different names, allowing you to resolve a specific instance based on the circumstances. Although there is some controversy if supporting this feature is a good idea or not, it certainly can be handy. To support this feature a new interface IKeyedServiceProvider got introduced in .NET 8 providing 2 new methods on our ServiceProvider instance: object? GetKeyedService(Type serviceType, object? serviceKey); object GetRequiredKeyedService(Type serviceType, object? serviceKey); To use it, we need to register our service using one of the new extension methods: Resolving the service can be done either through the FromKeyedServices attribute: or by injecting the IKeyedServiceProvider interface and calling the GetRequiredKeyedServic...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...