I know that my question has been responded lot of times, but most the responses addresses functions that I don't even use (like use include with images) and that makes me worry because maybe I'm not doing something that I should be doing.

When I'm validating the images, I first check for the size (2MB or less) and then check the extension of the file using:



Where $Whitelist are the extensions that I allow (only jpg, jpeg and png). After that I use getImageSize to verify that is really an image and if all the 3 conditions are met, then I create a new name for the image, add ".jpg" and then save it in an image folder (I don't know if this is important, but I also create a smaller version of the image to show in the page and if you want to see it in full size, you must click it and see the original image in a new tab).

The only thing I do with these images is show them with img src="" on my website, I never include images (actually I don't even know why some people do this [not criticizing, I'm being serious]) or use fopen and similar functions and the images folder can't execute php code.

Is that enough to not execute php code included in the images?

Is that enough to not execute some html/javascript code in the images? Because I don't want a XSS attack just because I was naive with the pictures and only considered apache executing the php code.

I must do something about possible images with virus? I think the size restriction, add a new name and always make sure to add .jpg at the end of the new name help me to mitigate this, but I'm not really sure.

I'm new with uploaded content and that's why I feel really paranoic about this (and all kind of user inputs... it's like being inside a pyramid where everything is cursed), so I'll really appreciate all the responses.

  • What do you mean, The only thing I do with these images is show them with img src="" on my website, I never include images? What do you think "<img src=" does, if not include the image in the web page?
    – AviD
    Commented Aug 19, 2013 at 8:31
  • Also why is this not a duplicate of: security.stackexchange.com/q/600/33, security.stackexchange.com/q/235/33, security.stackexchange.com/q/10109/33, or security.stackexchange.com/q/14881/33? For example...
    – AviD
    Commented Aug 19, 2013 at 8:38
  • @AviD: I'm talking about the Fuction Include() of php. I said that because in almost all threads about this, they end up talking about "yeah, be careful using 'include' with images", and since I'm only using img src="" instead of any kind of include in my php script, I said that to avoid that kind of assumptions.
    – Esteban
    Commented Aug 19, 2013 at 13:27
  • And about the duplicate, let's consider that those threads are 2 or 3 years old and there could be a lot of new attacks and/or defenses when talking about image uploads. I'm not asking "yeah, I heard about those attacks and want to know what should I do", I'm asking if what I'm doing is enough, since mine is a simple image upload supporting 3 formats, while others are using more complex stuff, like supporting all kind of images files (or even all kind of files), using the function Include or allowing huge files.
    – Esteban
    Commented Aug 19, 2013 at 13:36
  • While there may indeed be new attacks, the stated answers there are still relevant, and have not gone out of date. Also as the answers explain, these apply to HTML image inclusion ( "<img src=..."), and for "simple" images (not sure what you mean by that). And, according to those answers: no, what you're doing is not enough. I am still not clear on what else you are asking, beyond those questions?
    – AviD
    Commented Aug 19, 2013 at 19:46

1 Answer 1


First of all, you should check your (image) uploads because they can facilitate the exploitation of other bugs (like local file includes). Since there are virtually infinite possible attack vectors you will probably miss something but you should do your best.

  • Your solution for extension filtering is runtime-dependent: Apache for example will run evil.php.jpeg as a PHP script if the .jpeg extension is not registered in its configuration (this is an exceptional case though). I suggest to filter double extensions and filenames ending in '.'. Recommended read:


  • getImageSize() tells you if the uploaded file is really an image although you can place arbitrary content (like attack payloads, PHP or HTML/JS code) in some of the legitimate headers (think PNg comments or EXIF). One can also possibly create a file that is an image and valid in some other format at once. I suggest to resize/transform the uploaded image if possible.

  • As FakeRainBrigand pointed out, you should set the file permissions to non-executable to reduce the risk of OS-level execution (also some PHP configurations require scripts to be executable).

  • Size limiting and renaming are good practices!

  • I don't really know what you mean by "image with virus". One can exploit bugs in image renderer engines to execute code, and there is not much you can do about that, as detecting this kind of malicious code would require a whole other AntiVirus-like system that would eventually face the Halting problem.

  • 1
    About the .php.jpeg, it should also be noted to set user permissions to even octets (i.e. no execution ever), e.g., 644, and have a dedicated user own it if you won't delete it in PHP. Then once written, a separate poorly written PHP script can't make it executable or replace it with something else.
    – Brigand
    Commented Aug 17, 2013 at 12:36
  • Thanks for your response. About the extension filtering, actually that's just 1 layer of protection, since just before saving the image I rename it, then it shouldn't be a problem because evil.php.jpg now will become MyRandomName.jpg and at least as far as I know, that shouldn't be executed as php code (and the images folder is configured to not execute php). About the image with virus, when I started reading about this, I found some questions about scanning uploaded files with possible virus, I thought that since they're not executable files shouldn't be any problem, but I was still worried.
    – Esteban
    Commented Aug 17, 2013 at 12:45
  • After reading the 2nd point, now I'm using Imagick and the method stripImage() to remove all the extra info of the image and don't be susceptible to XSS in Exif data. With that, plus renaming files before saving, having the image folder without permissions to execute code, size limiting the images, the whitelist of extensions and using the nosniff header, I think it's ok now. Despite being the only answer, this is just what I needed, thanks again.
    – Esteban
    Commented Aug 19, 2013 at 13:45

You must log in to answer this question.

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