It's clear that the system has to filter user input. I always thought that the standard is also to check user uploaded files for malware/shells.

I'm curious if above is really needed. There is a PHP (Laravel) application that is accepting file uploads from the user (via REST API). The file will be stored on the server temporary, after that, it will be uploaded to S3 storage.

The idea is that our users can upload files to share internally. Some kind of dropbox for internal share.

I want to give our users full freedom for uploading files, but how safe will it be? Is it really necessary to validate uploaded files if those are stored only temporary on the server and why?

  • It depends entirely upon the kind of service you are trying to provide. Why are users trying to upload files to your system? Are you storing photos? Sharing documents? Or just providing generic file storage capabilities? The answer varies wildly depending on what you are actually trying to do for your users. Jul 23, 2019 at 17:12
  • 2
    The main security implication is whether the server can be tricked into executing a file. Jul 23, 2019 at 22:44
  • 2
    @TimMishutin If your sole concern is protecting the server then ensuring that there is no way that a remote user can trick the server into executing an uploaded file should be sufficient. If you want to minimise the risk of your service being a vector for malware transmission between your users on the other hand then you are going to need to check the uploaded content for known malware before making it available for download this applies even for non executable files as exploits that target vulnerabilities in file handlers are of course a thing too.
    – MttJocy
    Jul 24, 2019 at 11:06

2 Answers 2


There's three different concerns that get conflated a lot:

  1. You need to make sure the server can't be tricked into executing code.
  2. You need to make sure the server can't be tricked into serving a user-uploaded file with a Content-Type (html, svg, xml) that allows Javascript to execute within the site's origin when a user accesses the file.
  3. Optionally you might want to stop users from accidentally sharing malware by blocking it from being uploaded.

Part 3 is optional. You can imagine the extreme case where you're literally making a website for people to upload malware samples for inspection. In that case, you wouldn't want to implement #3 at all. That server shouldn't do any filtering and shouldn't prevent any files from being uploaded. Files are just bytes; as long as nothing is executing them, they aren't inherently unsafe to store or process. For regular sites, #3 is a nice-to-have, but it should be prioritized after #1 and #2 and can not be done instead of them. Parts #1 and #2 are always necessary.

The main way #1 can be failed is if you're using PHP and you save the files to a directory where PHP is enabled. Then if the user uploads a file with the extension .php, the server will executes it if the user requests it. You can prevent this by disabling PHP on the directory that uploaded files go into. You could also have an explicit whitelist of extensions which doesn't include .php. You should test your application by trying to upload a php file that contains some php code (<?php phpinfo();) and verify that the upload is either blocked, or shows up exactly as you uploaded it.

To solve #2, you need to make sure files are only served with specifically-allowed "Content-Type" headers. Most web servers default to choosing the Content-Type header based on the file extension, so you either need to override that so all files get a safe Content-Type ("application/octet-stream" is a good default that tells the browser to download the file) with maybe a few content types whitelisted (mainly just non-svg images), or make it so there's a whitelist of allowed file extensions. You should test your application by uploading an .html file and making sure that it does not display as a web page. It needs to be blocked, or prompt your browser to download instead of viewing in-place when you access it.


There are two potential implementations for this:

  • Check the file hash against VirusTotal
  • Implement an internal anti-malware scan

The security of your application and storing the temporary files securely is up to your secure development skills. There is a potential vector, where an insider threat or a malicious actor would upload a ransomware virus like .exe, than send out an e-mail to launch this file from a legitimate source, your file share.

Overall this is something that currently is not stated as a must have practice, because a skilled attacker can bypass both of these methods.

It is nice to have it although and could potentially prevent some attacks. If your company is security aware and would like to limit the risk, this is a good way to do it.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .