OpenFlax Design Goal #1: Security

Of course all web server authors have a concern for security, but for OpenFlax it is explicitly stated as the primary requirement.

Please understand that although this is the case, the author(s) cannot make any guarantees about the security of OpenFlax. All efforts have been made to ensure there are no holes in the code, but if you choose to use it, you do so entirely at your own risk.

Also, please understand that 'security' in this sense doesn't have anything to so with SSL or encryption of any sort. It means serving web pages while not being a liability to the integrity of the computer system that it's running on.

To this end, OpenFlax has tried to adhere to DJB's seven fundamental rules as they might apply to a web server:

1. Don't treat files and programs as addresses.

   Most web servers consider a request like http://www.w3c.org/foo/bar/baz.quuz to refer to a file called baz.quuz in a directory called foo/bar in some 'webserver root' directory.

   By itself, OpenFlax does not (and in fact, cannot) do this. It merely treats /foo/bar/baz.quuz as the name of some resource. In order for that request to be interpreted as a filename, an extra handler must be configured. openflax.handler.file, available seperately in the openflax_handlers application, is one such handler.

2. Do as little as possible in setuid programs.

   OpenFlax doesn't do anything setuid (or setgid, for that matter.) It doesn't run CGI's, much less try to run them as some other user.

3. Do as little as possible as root.

   OpenFlax doesn't do anything as root. In fact, OpenFlax refuses to be started as root (unless it is intentionally misinformed by someone messing with the USER environment variable).

   Unfortunately, on some systems this is simply not possible; if you wish maximum security, you are suggested to run it only on operating systems with a good security record.

   Additionally, if you wish to serve your web site from port 80, you should use NAT (network address translation) to map port 80 onto a user port such as 8080.

4. Move seperate functions into mutually untrusting programs.

   In Erlang's case, mutually untrusting modules and/or processes. In reality, the modules and processes in OpenFlax could do a better job in not trusting each other.

5. Don't parse.

   OpenFlax uses file:consult/1 for its configuration files - a method which has been battle-tested by numerous Erlang programs before this one.

   On the other hand, parsing HTTP headers is, of course, unavoidable.

6. Keep it simple, stupid.

   There's nothing inherently complicated about writing a web server (except parsing HTTP headers, and that's limited to openflax.http.parse.) The idea is to keep it as simple as possible - but no simpler.

7. Write bug-free code.

   Not as hard as it sounds, if you can unit-test (the shell really helps, here) and minimize the interactions between modules.