Content-Type bypassing remains a frequently encountered vulnerability in web applications despite being well-documented for years. This attack exploits insufficient validation of file uploads, allowing attackers to upload malicious files by manipulating HTTP headers. Understanding this vulnerability, its exploitation techniques, and effective defences is essential for security professionals and development teams alike.
This post examines the technical mechanics of Content-Type bypassing, real-world exploitation scenarios, and comprehensive defensive strategies.
What Are Content-Type Headers?
When you upload a file to a website (a resume, profile picture, or document), your browser sends that file to the server along with metadata describing what kind of file it is. This metadata includes the Content-Type header, which might say “image/jpeg” for a photo or “application/pdf” for a document.
Here’s what a typical upload request looks like:

The Vulnerability: Trusting User Input
The core problem is simple. Content-Type headers are trivially easy to fake. An attacker can take a malicious file (say, a PHP web shell that would give them remote access to your server) and tell your application, “This is totally just a harmless JPEG image.”
If your application only checks that header and doesn’t verify the actual file contents, it will accept the malicious file. This is like a security guard who checks that your ID says “Authorised Personnel” without actually looking at the photo or verifying it’s real.
Let’s look at a vulnerable code example:

This code checks the Content-Type (stored in `$_FILES[‘upload’][‘type’]`), sees “image/png,” and saves the file. But if an attacker uploads `backdoor.php` and changes the Content-Type header to “image/png,” this code happily saves that PHP file to the server. If the uploads folder is accessible via the web and the server executes PHP files, the attacker can now run commands on your server.
## How Attackers Exploit This
The exploitation process is straightforward, which is part of why this attack remains popular. Attackers use tools like Burp Suite or browser developer tools to intercept and modify their upload requests. Here’s the typical workflow:
**Step 1: Find the Target**
They identify an upload feature on your website and test what file types are accepted or rejected.
**Step 2: Intercept the Request**
Using an intercepting proxy, they capture the upload request. It might look like:

Step 3: Modify the Header They change the Content-Type from application/x-php to something accepted, like image/jpeg.
Step 4: Execute Once uploaded, they access the file directly (if it’s in the web root) or find another way to trigger its execution.
The concerning part is how little technical skill this requires. With basic tools and a tutorial, someone with minimal experience can perform this attack.
Real-World Impact
From a threat intelligence perspective, this vulnerability is exploited in several contexts:
Web Shells for Persistent Access: Attackers upload web shells disguised as images. These shells provide a control panel for executing commands, browsing files, and accessing databases. Popular shells like WSO or c99 are specifically designed for this purpose.
Initial Access for Ransomware: Ransomware operators often gain initial access through upload vulnerabilities. Once they have a foothold, they move laterally through the network before deploying encryption.
Supply Chain Compromises: Partner portals and vendor systems with weak upload validation become entry points into larger organisations.
The business impact can be severe. A successful web shell upload can lead to data breaches, system compromise, and regulatory violations. Incidents involving bypassed upload forms have resulted in significant remediation costs and reputational damage.

Building Effective Defences
Defending against Content-Type bypassing requires multiple layers of security. No single control is foolproof, so we implement defence in depth.
Validate File Contents, Not Just Headers
Instead of trusting the Content-Type header, examine the file itself. Every file format has a unique signature (called magic bytes) at the beginning of the file:
- JPEG files start with FF D8 FF
- PNG files start with 89 50 4E 47 0D 0A 1A 0A
- PDF files start with 25 50 44 46 (which spells “%PDF” in ASCII)
A simple validation function might look like:

Libraries like python-magic or Apache Tika provide more comprehensive file type detection that handles edge cases and supports numerous formats.
Control File Storage Location
Store uploaded files outside your web root directory. This means even if an attacker uploads a malicious script, the web server won’t be able to execute it directly. Serve files through a download script that applies proper security headers:

Implement Extension Whitelisting
Maintain a strict list of allowed file extensions and reject anything that doesn’t match. Avoid blacklisting (blocking specific extensions), as attackers can use obscure variants like .php3, .phtml, or .phar.
Combine extension validation with content validation. A file must pass both checks.
Configure Server-Level Protections
Configure your web server to refuse execution of scripts in upload directories. For Apache:

Sanitize Filenames
Clean user-supplied filenames to prevent path traversal attacks and other injection techniques:

Add Malware Scanning
Integrate antivirus scanning into your upload workflow. Tools like ClamAV can scan files before they’re made available to users. While not foolproof, this catches many known malicious files.
Set Proper File Permissions
Ensure uploaded files have restrictive permissions (644 or 444) so they can’t be executed by the web server user.
Detection and Monitoring
Beyond prevention, you should monitor for bypass attempts:
- Log all upload requests and look for patterns like high volumes from single IPs or unusual file types
- Alert on files uploaded to directories that shouldn’t receive them
- Monitor for the creation of executable files in upload directories
- Track Content-Type mismatches where the declared type doesn’t match the actual file content
Why This Matters Beyond File Uploads
Content-Type bypassing illustrates a broader security principle: never trust client-supplied data. Whether it’s an HTTP header, a form field, a URL parameter, or a cookie value, anything coming from outside your system should be treated as potentially malicious.
This mindset shift is crucial. Security isn’t about implementing a checklist of controls but about understanding trust boundaries and validating data at those boundaries. The Content-Type header crosses a trust boundary (from an untrusted user to a trusted application), so it must be validated.
For non-technical readers, this is why your development and security teams sometimes seem overly cautious about features that seem simple. That innocent-looking upload form represents multiple potential attack vectors that require careful design and ongoing vigilance.
Conclusion
Content-Type bypassing continues to appear in security assessments and real-world attacks because it exploits a common misconception: that client-supplied metadata can be trusted for security decisions. The attack is simple to execute but can have serious consequences, from data breaches to complete system compromise.
The good news is that this vulnerability is entirely preventable. With proper validation of file contents, secure storage practices, server hardening, and defence in depth, you can effectively eliminate this attack vector from your applications.
As you review your own systems or work with development teams, ask the right questions: Are we validating file contents or just headers? Where are uploaded files stored? Can the web server execute files in upload directories? These questions can reveal vulnerabilities before attackers find them.
Security is an ongoing process of identifying assumptions, testing trust boundaries, and implementing layered defences. Content-Type bypassing is just one example, but the lessons learned here apply broadly across application security.
Header image > Photo by the blowup on Unsplash.
Defence image > Photo by Saj Shafique on Unsplash.










Recent Comments