The file upload feature is becoming a more and more essential part of any program. That’s because, on many platforms, users usually need to upload their photo, CV, or a video showcasing a project they are working on.

But what can we as testers do if they don’t upload what the product owner requested when writing the specifications?

In this article, we’re going to dive into some ad-hoc test cases of what you can perform when testing the file upload feature of your application.

File Upload Testing in 11 Steps

  1. Firstly, start with the allowed extensions. Are you able to upload these extensions on all supported browsers or devices?
  2. Move on to file names. What happens if you use weird characters or different types of naughty strings? And if we add null bytes, e.g., php%00.jpg? As a result, the .jpg gets truncated and .php becomes the new extension. Look for other bad regex examples while constructing the file name.
  3. Next, see if you can upload a file where the name is just an empty space. Then an emoji. Will it work if the title is 500.000 characters long? We sure hope it doesn’t!
  4. What if you decide to upload a 1GB .pdf.? Simple, test the size limits because a 1GB .pdf file shouldn’t be allowed to upload.
  5. Check if all user roles from your app are allowed to upload files. Try using the session ID of a user who shouldn’t be allowed to do file uploads. Also, is the user logged in? Or are they able to do the file upload without even being logged in? Import the request in Postman and test this out as well.
  6. See if you are able to upload malicious data. Let’s say you change the extension of an .exe file to a .jpg. That should not work. Additionally, it’s never a good idea to allow .zip files to be uploaded. Try it out on Gmail and see if it works (it shouldn’t).
  7. Would you be able to convince the browser app to upload the file to a malicious website using the Cross-Site Request Forgery method?
  8. What if you tried to request the file you just uploaded 1000 times? The requests are small, yet the responses are much larger. Should you be able to do that? It might cause some delays on the server trying to process those instant 1000 download requests, so it’s not a good idea to allow this from the server-side, but it obviously depends on the product.
  9. On a publicly accessible feature, should we be able to upload illegal, offensive, or dangerous data? What about copyrighted data? (think of YouTube, try to upload a video containing copyrighted music, see what happens).
  10. Regarding the API request when doing the file upload, see if the request also has the content-type validation header. It definitely should!
  11. Lastly, we know that image rewriting techniques destroy any malicious content injected into an image. So, why not test this one out too? See here for more details on how to do it. 

Note: We were inspired by OWASP’s file upload cheat sheet from a developer’s point of view.

Do you have other ideas of what to test when it comes to file uploads? We’re always eager to discuss testing theories, drop by (virtually) anytime! https://calendly.com/betterqa