When a hacker takes over the public server, you have to assume the worst case that they can do everything the public server is allowed to do. That means in case of a compromise, any security precautions implemented on the public server are inefficient. You can only rely on those precautions you have on the private server.
- Make sure that the public server only has permission on the private server to store files in that one folder. You certainly don't want it to put some files into system folders.
- Set file permissions on the private server so that no user is allowed to execute the uploaded files (but keep in mind that simply opening a malicious document might exploit a vulnerability in the reader software which might allow code execution).
- Storing the files from the frontend should be the only purpose of that folder. There should be no other data in there which might get overwritten.
- Setting a quota for the maximum size of that folder can also be a reasonable protection against an intentional or unintentional denial-of-service attack through filling the whole storage space of the server with garbage.
- Having a virus scanner on the private server to scan the incomming files can't hurt. But don't trust it too much. Remember that a malware scanner can only find what it knows.
- A sensible precaution can be to only allow files with specific extensions to be uploaded. But keep in mind that the file extension is not a reliable method to check for a type of file. Finding out that
hello.jpg
is actually a renamed executable is non-trivial. However, it prevents accidental execution due to double-clicking in most cases.
Another possible way of doing this is to use a pull-method. Don't have the public server push its files to the private one. Have the private server check for new files on the public server at regular intervals and pull them. This gives you greater control over what files to pull. You can, for example, only pull files with filenames matching a specific pattern.