In very basic terms it means that some level of sophisticated file type and content-type verification will be performed in a manner that is theoretically secure. For example, Whatsapp shouldn't have allowed HTML to be uploaded if it's disguised as an image thumbnail. That's pulling a page right out of 2002.

This is very easy to do 80% of the way, and difficult to do with the remaining 20%. The last mile of file validation is extremely fickle because it requires an understanding of what the uploading library is doing under the hood. You can minimize your risk by carefully choosing files to accept, understanding how they're parsed by your libraries and correctly disallowing everything else.

Practically speaking, you should at a minimum:

1. Whitelist acceptable file types,

2. Perform server-side, not client-side validation,

3. Validate the file types not only by extension, but by contents,

4. Disallow filenames from being set by user input, and ideally hash them before presenting them back,

5. Store the files on a separate host/CDN,

6. Only allow the uploader to retrieve files uploaded by the user, and not from local or remote resources. If you must allow local directories, maintain strict permissions, and do not allow loopback resources.

That's a great start. To go further, you should investigate which library to use carefully and consider how legitimate files you are choosing to whitelist can still be dangerous. For example, you can trigger an XSS with a valid SVG. You can attack system memory with fraudulent JPG sizes. You can trigger server-side request forgery by uploading 127.0.0.1, etc.

For simple image types, you can avoid a lot of this machinery by always resizing and converting images serverside, so that attackers simply don't have control over the bits of any image they upload. This used to be the recommended countermeasure back when GIFARs were a thing.

Obviously, a trickier problem when those images are encrypted.

> 2. Perform server-side, not client-side validation,

WhatsApp is end to end encrypted, so how is server side validation possible?

It's not :) I was being prescriptive about general purpose applications, sorry!

In this specific scenario, the files should be validated before a user is presented with them and after they are received and decrypted. The client-side validation is only so that the attacker cannot bypass it and leave the server vulnerable; you can instead offload this to the other party, which in this case is client 2 in a client <-> client communication rather than client <-> server communication.

The point is that it happens somewhere out of an attacker's control in a trusted environment. Obviously, the same limitation applies to server-side validation, which is that the file must be validated without triggering a latent exploit within it. That's why it's also important to understand the parsing libraries.

The post describes that the client ensured only files with specific mimetypes could be uploaded. However, patching the client allowed files to be uploaded while that shouldn't have been allowed. Most likely they mean the whatsapp server now also checks the mimetype of uploaded files, rejecting those that aren't ok.