Choosing web server software for security
Solution 1:
nginx is hosting couple of percent of the global number of websites, so it is far from being obscure. That is hundreds of thousands, if not millions of sites, and as such nginx is large enough to be a worthwhile target for exploits.
nginx already has had security issues, and the open source community has disclosed vulnerabilities to the author, who has fixed them. Search for "security" in the changelogs, and you'll see that there is a working process in place: http://nginx.net/CHANGES-0.6
So nginx has pretty much the same process as Apache for fixing security issues. It may be a smaller team, and less formalized, but it works much the same way.
Having a small, tight codebase, with a clean and simple arcitecture, is a major improvement from a security standpoint. Less code = statistically fewer bugs. Experiences shows that as a codebase gets larger, the bug count grows more than linearly. Assuming a similar code to error ratio, a smaller codebase will lead to less exploits.
Would it be irresponsible from a security standpoint to go with nginx, due to its smaller user base? I would answer absolutely no, nginx is a very good choice, also for the security minded.
I would however propose to look at HTTP server security in a slightly different way. There is the issue of a buffer overflow in the http deamon, which could lead to a exploit against the http deamon itself. For most designs, the impact of this can be minimized fairly easily, by using OS-level tools such as jails / croot / virtualization to 'containerize' the http deamon and restrict the effect of a successful attack.
An attack against a web application can be worse, and is more common, especially for in-house developed webapps, which often have not been security audited by experts. Examples are using cross side scripting or SQL injection to do evil things with user data, withdraw money, steal a database of usernames and passwords etc.
Apache has one major benefit in the area of webapp security, that benefit is the 3rd party mod_security module. Think of it as a giant regex engine for HTTP requests, which allows you to do pattern matching and filtering on any part of the HTTP call. This can be used to significantly reduce the attack surface against your own webapp code.
For a security-minded open source webapp stack, I might use:
- a containerized nginx instance for load balancing, on a separate physical or virtual server in front of the webservers, proxying HTTP requests to backend webservers.
- Apache with mod_security for the webservers.
You could also do it the other way around -- Apache with mod_security performing load balancing front of nginx webservers. It is largely a question of where you want the CPU load to be -- HTTP filtering with mod_security takes a fair amount of CPU ressources, so a Apache load balancer with mod_security might not handle more than a handful of backend webservers. The congestion on the load balancer is greatly reduced if the load balancer is a small, fast nginx instance, and the webservers do their own mod_security filtering.
This gives you a containerized HTTP proxy as a layer of indirection between the public Internet and your webapp, and mod_security as a scalable HTTP level firewall in front of your webapp code. But be prepared for this, especially mod_security, to take a lot of time to set up and get fully working without unwanted side effects.
Solution 2:
Obscurity as a security model is no basis for good IT.
That however doesn't mean that Nginx is not the best solution for you. The application is just one point of security.
Having not done the research myself I can't say that the advantages are more towards Apache, but from looking at your list the case for Nginx is weak.
Solution 3:
I faced thsi same question a while back and wen with Sun Web Server. It is an NSAPI server even though it also has a Java container. The core of the server is open source and it is free. It is known for its security. It has a simple interface for administration and it is rock solid. It is actually the old Netscape fastrack server.
Solution 4:
One thing against nginx is that the current version in Ubuntu 10.04 LTS is still at .7 where mainstream nginx is at .8 and iterates towards .9. Apache seems to be better supported in terms of updates in the official Ubuntu LTS packages. As a single person administering 7 servers at a small organization and other tasks at hand as well it is a pain to document all the non-standard software installations and keep them up to date. Therefore we stick to whatever is in the LTS distro and just keep the server updated using standard measures.