I am developing a website that accepts uploading a specific type of data. In particular, the data must be a human-readable text string in the order of thousands of characters. The data is input into a text field that is then uploaded to the server when the user clicks a button.

I want to ensure that all data entered into the text area conforms to the accepted format, i.e., I want to filter out any content that malicious users might upload, such as images, video, executables (or any binary for that matter), etc... How can I achieve this goal? My current ideas are the following:

Backend (written in Java)

  • Data stream content guessing (magic characters, identifiers at the beginning of the stream),
  • File type probing (by considering the entire uploaded stream as a single file),
  • MIME type probing.

Frontend (running on Tomcat, plain old HTML + Javascript)

  • Content length verfication (data must not be huge, i.e., > x KB/MB),
  • Javascript MIME type verification (don't have any experience with any libraries for this...).

What other options are there to minimize the risk of users uploading unwanted content, or in general content that is not of a given type?

  • I'm confused. Are users uploading a file, or submitting a form with a text field? You said The data is input into a text field, but also talk about MIME types and file types. If it's just a text field, all you would need to do is some sort of validation on that string, no?
    – neilsimp1
    Dec 28, 2017 at 13:14
  • @neilsimp1 I was thinking of taking the text string at the backend, and treating it "as if" it were a file, so that I can employ file type probing algorithms Dec 28, 2017 at 13:48
  • Run your input through a spell check and reject it if you see too many errors. Dec 28, 2017 at 13:59
  • @DanPichelman: only a good idea if there is only one accepted language for the text, which I guess is not.
    – Doc Brown
    Dec 28, 2017 at 15:58

1 Answer 1


Of course do the check on the backend. The user may manipulate the frontend all they wish.

It is a good idea to add such check on the front-end too, if there is a realistic chance that the user may make an accidental mistake, and the back-end cannot provide enough information to the front-end to handle the error (e.g. if the back-end returns 403/forbidden without any additional info). Otherwise, don't bother.

As for the check on the back-end: is it enough that the input is ASCII, or does it need to be Unicode? If former: just refuse anything with characters outside of the range 32-127+ CR and LF. If the latter, I am worried that text written in some languages will often look like a binary... You can try to demand that it is utf-8 encoded, and then check, on the back-end (by simply decoding it) that it is valid utf-8. As a by-product, you are getting it in a String, at which point I guess your back-end will be able to handle it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.