File upload testing in 11 steps
File upload functionality is essential across modern applications - from user profile photos to CVs, project videos to document attachments. But file uploads also represent one of the most exploited attack vectors in web security. This technical checklist covers the 11 critical test cases every QA engineer should execute when validating file upload features.
Why file upload testing matters
File upload vulnerabilities consistently rank among the most dangerous security weaknesses in web applications. Attackers can exploit improperly validated uploads to execute malicious code on servers, bypass authentication, exfiltrate data, or launch denial-of-service attacks. What appears to be a simple feature can become an open door for complete system compromise if not thoroughly tested.
Attackers upload executable files disguised as images or documents. Without proper validation, servers may execute malicious code, leading to complete system takeover.
Malicious filenames containing sequences like "../" can trick applications into writing files outside intended directories, overwriting critical system files.
Without size limits, attackers can exhaust server storage or memory with massive file uploads, or trigger infinite loops with specially crafted file contents.
File upload testing: Steps 1-6
The following checklist is adapted from OWASP's File Upload Cheat Sheet, translated from a developer's perspective to a QA testing perspective. Execute each test case across all supported browsers and devices.
Start with the extensions your application explicitly allows. Test that each permitted extension uploads successfully across all supported browsers and devices. Then verify that disallowed extensions are properly rejected with clear error messages. Check both uppercase and lowercase variants (.JPG vs .jpg) and mixed case (.JpG).
File names are a prime attack vector. Test with weird characters, naughty strings, and injection attempts. Try null byte injection (e.g., evil.php%00.jpg) where the .jpg gets truncated and .php becomes the actual extension. Test path traversal patterns (../../../etc/passwd) and SQL injection in filenames.
Push filename handling to its limits. Upload files with names that are just a single space, just emojis, or 500,000 characters long. Test empty filenames, filenames with only special characters, and filenames that match reserved system names (CON, PRN, AUX on Windows). The application should handle all these gracefully.
Test that file size restrictions are enforced both client-side and server-side. Attempt to upload files significantly larger than the allowed maximum - a 1GB PDF should never be accepted if your limit is 10MB. Bypass client-side validation using browser developer tools or Postman to verify the server also enforces limits.
Verify that only authorized users can upload files. Test by hijacking a session ID from a user who shouldn't have upload permissions. Check if unauthenticated users can access the upload endpoint. Import the upload request into Postman and manipulate authentication tokens to verify server-side authorization checks.
Verify the application validates file content, not just extensions. Rename an .exe file to .jpg and attempt to upload it - this should fail. Test with polyglot files that are valid in multiple formats. Try uploading .zip files (often disallowed due to zip bomb risks).
File upload testing: Steps 7-11
These final test cases cover advanced security scenarios including CSRF protection, rate limiting, content moderation, API validation, and image processing security. Each represents a potential vulnerability that sophisticated attackers routinely exploit.
Cross-Site Request Forgery attacks can trick browsers into uploading files to malicious destinations. Verify the upload endpoint validates CSRF tokens. Create a test page on a different domain that attempts to POST a file to your upload endpoint - this should fail.
Rapid repeated requests can overwhelm servers. Script 1000 consecutive file download requests for the same uploaded file - the response is larger than the request, so this amplification can cause server delays. Verify rate limiting kicks in.
For publicly accessible upload features, verify the application handles inappropriate content. Attempt to upload illegal, offensive, or dangerous material. Test with copyrighted content - platforms like YouTube automatically detect and block copyrighted music in video uploads.
Examine the API request during file upload using browser developer tools or a proxy. Verify the request includes Content-Type validation and that the server validates it matches actual file content. Test by sending requests with mismatched Content-Type headers.
Image rewriting (re-encoding uploaded images through a library like ImageMagick) destroys malicious content injected into image files. Test whether your application performs image rewriting. Attempt to upload images with embedded JavaScript or PHP code in EXIF metadata - after download, verify the malicious payload has been stripped.
Common file validation checks
Use this reference table when planning your file upload test cases. Each file type has specific validation requirements and associated risks that your testing should address.
| File Type | MIME Type | Security Risks | Validation Checks |
|---|---|---|---|
| Images (JPG, PNG, GIF) | image/jpeg, image/png, image/gif | Embedded scripts in metadata, polyglot files | Magic bytes, image rewriting, EXIF stripping |
| PDF Documents | application/pdf | JavaScript execution, embedded files, XSS | Content scanning, size limits, sandbox viewing |
| Office Documents | application/vnd.ms-*, application/vnd.openxmlformats-* | Macro execution, embedded OLE objects | Macro detection, format validation, sandboxing |
| Archives (ZIP, RAR) | application/zip, application/x-rar-compressed | Zip bombs, path traversal, hidden executables | Decompression limits, nested archive blocking |
| Video/Audio | video/mp4, audio/mpeg | Codec exploits, embedded content, large sizes | Transcoding, metadata stripping, size limits |
| SVG Images | image/svg+xml | Embedded JavaScript, XSS, SSRF via external refs | XML sanitization, script removal, CSP headers |
Always test Content-Type spoofing by sending files with incorrect MIME types. A well-secured application validates both the declared Content-Type header AND the actual file content using magic bytes or file signature analysis.
Recommended testing tools
These tools help automate and systematize file upload testing. Combine automated scanning with manual exploratory testing for comprehensive coverage.
Intercept and modify upload requests in real-time. Test Content-Type manipulation, inject payloads into filenames, and automate repeating tests with Intruder. Essential for API-level file upload testing.
Import browser-captured requests and modify authentication tokens, headers, and file contents. Build collections of file upload test cases that can be run repeatedly across environments.
Open-source web security scanner that can automatically test file upload endpoints for common vulnerabilities including path traversal, CSRF weaknesses, and content-type bypasses.
A curated list of strings known to cause issues in software - use for filename testing. Includes null bytes, Unicode edge cases, SQL injection patterns, and XSS payloads.
OWASP file upload cheat sheet: key security rules
The OWASP File Upload Cheat Sheet provides the definitive security guidelines for implementing safe file upload functionality. Here are the critical rules every QA engineer should verify during testing.
Server-side validation is non-negotiable
Client-side validation (JavaScript checks in the browser) is a convenience feature, not a security control. Attackers bypass it trivially using browser dev tools, curl, or Postman. Every validation rule - file type, size, content - must be enforced on the server. During testing, always bypass client-side checks to confirm server-side enforcement exists.
Validate content, not just extensions
OWASP recommends validating files using magic bytes (file signatures) rather than trusting the file extension or the Content-Type header sent by the client. A file named report.pdf with Content-Type application/pdf could contain executable PHP code. Your server should read the first few bytes of every uploaded file and compare them against known signatures.
| File Type | Magic Bytes (hex) | What to test |
|---|---|---|
| JPEG | FF D8 FF |
Rename .php to .jpg - should be rejected |
| PNG | 89 50 4E 47 |
Upload PHP with PNG header prepended |
25 50 44 46 |
Test polyglot PDF/JavaScript files | |
| ZIP | 50 4B 03 04 |
Upload zip bomb (nested archives) |
Store uploads outside the web root
OWASP strongly recommends storing uploaded files in a location that is not directly accessible via URL. If uploads go to /var/www/html/uploads/, an attacker who uploads shell.php can execute it by visiting yoursite.com/uploads/shell.php. Verify that uploaded files are served through a controller that sets proper Content-Disposition headers, not directly from a public directory.
Rename files on upload
Applications should generate random filenames (UUIDs or hashes) for uploaded files, discarding the original filename entirely. This prevents path traversal attacks, filename-based exploits, and makes it harder for attackers to guess the URL of uploaded content. During testing, verify that the stored filename bears no relation to the original.
Set upload size limits at every layer
OWASP recommends enforcing file size limits at the web server level (nginx/Apache config), application framework level, and application code level. Test by sending oversized files directly to the API endpoint - if only the application code checks size, the web server may still accept and buffer a 10GB file before the application can reject it.
For each upload endpoint, verify: (1) server rejects files with wrong magic bytes, (2) files are stored outside web root, (3) filenames are randomized, (4) size limits work at the server config level, (5) Content-Disposition headers prevent inline execution, (6) antivirus scanning runs before files are accessible to other users.
For automated OWASP compliance testing, BetterQA's AI Security Toolkit includes DAST scanning that checks file upload endpoints against OWASP guidelines. It detects missing Content-Type validation, path traversal vulnerabilities, and missing size enforcement automatically.
How BetterQA tests file upload security
At BetterQA, file upload testing is a standard component of our security testing services. Our team of 50+ QA engineers systematically validates upload functionality against OWASP standards while adapting test cases to each application's specific requirements and risk profile.
We use a combination of automated scanning with tools like Burp Suite and OWASP ZAP, plus manual exploratory testing for edge cases that automated tools miss. Our engineers document findings using BugBoard, which captures screenshots, network requests, and reproduction steps in a standardized format that developers can act on immediately.
For applications where file uploads are a core feature - document management systems, social platforms, content management - we recommend integrating file upload security tests into CI/CD pipelines. This ensures that new code changes don't introduce regressions in upload validation logic.
Frequently asked questions
Need help with security testing?
Talk to our team about comprehensive file upload security testing for your application.
Book a discovery call“File upload testing is where security meets functionality. A single bypass can turn your file upload into an open door for attackers.” — Tudor Brad, Founder of BetterQA (15+ years in QA)
Need help with software testing?
BetterQA provides independent QA services with 50+ engineers across manual testing, automation, security audits, and performance testing.
