A java application I'm working on has a file upload component, and I want to validate that only certain file types are allowed. I realize checking file extension alone is not sufficiently reliable, so I've started validating the hex signatures of the uploaded files. Have been using this for reference: http://www.garykessler.net/library/file_sigs.html

So, this application will expect some OOXML files, but it seems that each of these (docx, pptx, xlsx) have the same hex signature (50 4B 03 04 14 00 06 00), with no subheader to differentiate them.

Is there a good way to differentiate these, or, should I implement it whereby if the file extension is an OOXML file we accept, and the shared hex sig is correct, allow it through? Are there any additional security concerns from implementing the latter?

  • (FWIW, the magic number at the front of zip files is from the local header, repeated for each contained file and isn't necessarily at the front (although if it isn't, the file may be dodgy). The proper magic number is at the end.) Commented Oct 20, 2017 at 21:34

1 Answer 1


All of the OOXML file formats are actually zip archives with specific contents. That makes telling them apart a bit tricky, unless you're prepared to open them and examine the contents.

Whether this is a problem depends on what you're doing with the files. If you're just storing them for later download, and you've implemented good segregation between user uploads and files which are executed by the server, it might not matter. If you're using a server which accepts .jar files, and the upload folder is considered executable by the server software, it could be a big problem - .jar files are also zip archives with specific contents, so you could be letting users upload their own server side code if you're not careful.

Equally, opening the zip archives to check the contents can be dangerous - they might expand into large files which fill the system storage, for one example. If you're extracting data from within the files already, you might have protections against this kind of malicious file in place, though, so it might not cause problems.

Personally, I'd concentrate on ensuring that the upload function doesn't allow for any server executable code to be uploaded, whether this is by putting file uploads in a directory which doesn't allow execution of the contents, enforcing the file extensions allowed for both upload and execution (making sure they are different!), and potentially running some form of AV on uploads, ensuring that it isn't vulnerable to maliciously crafted zip archives.

You must log in to answer this question.

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