Section 9. Security

Back in the evil dark days of the WWW it was believed that a Web server should bend over backwards to accommodate any client written by anyone at any time no matter what the quality. For this reason most Web servers will allow nearly any malicious payload you send at them to pass right on through to your applications and network. Typically the only way to protect yourself is to create a blacklist^[17]of known attacks and block them with special security tools.

^[17] In the security world it's an established practice to use a "whitelist" rather than "blacklist" when trying to create a secured access policy. Instead of configuring your security to say "I accept everything, except…" you configure it with "I reject everthing, except…".

Mongrel takes a more proactive and strict approach to Web server security. As an example, Mongrel's HTTP processing is handled by a parser that has strict grammar specifications and exact size limits on all elements. Turns out if you simply reject anything that doesn't follow the HTTP 1.1 grammar, then you reject most security attacks without effort.^[18]

^[18] Zed has a theory that there's a correlation between ambiguity in the grammar specification for HTTP 1.1 and potential for security defect in the Web server or client protocol handler.

In addition to using a parser, Mongrel has extensive testing (at least 90% coverage), a full security policy, and a frequent audit process that involves some advanced auditing and validation techniques such as "fuzzing." By following a consistent security policy and using the most advanced testing tools available, the Mongrel team is able to keep the number of potential security defects down, and be proactive about it rather than reactive. While it's impossible to say Mongrel is completely secure, you can at least verify what policies are in place and make your own judgments.