The server is designed to run almost like a simplified file server in a POSIX machine. This implies a significant attack surface and a lot of potential for abuse.

(D)DOS attacks are pretty easy to create : the server is single-threaded and uses persistent connections but no authentication. This is not a security hazard, at least in a lab environment where there should be only one user.

There are many kinds of known, unknown and potential risks that require careful coding and safe development practices. The attack surface is reduced by limiting the system to its core functionality and keeping things as simple as possible (KISS).

But what about the unknown bugs ?

One solution is to use sandboxing techniques and implement inherent UNIX protection mechanisms. This way, if the system ever goes bad, the potential damage is contained to a portion of the system. Two methods protect this server:

• If the server is started with root privileges, and if the necessary informations are provided, the current user and group ID are changed to a non-privileged user, with limited rights.
• If the server is started with root privileges, the program is chroot()ed to the current working directory (or another one, if provided) so it can't access the rest of the system.

These are "last lines of defence" methods, which are complemented by many routine checks :

• The server (if correctly configured) will not serve files or directories that it doesn't own, which prevent accidental exfiltration of data.
• URIs must be filtered, rejecting any path containing two consecutive dots.
• No open directories. This reduce coding efforts and bugs, as well as removes a potential exfiltration method.

Of course, a user can always configure the server badly...

Many security considerations are covered in « The Tangled Web - AGuide to Securing Modern Web Applications » by Zalewski, Michał