Nginx, an open source web server that's relatively new on the market, has been attracting some interest lately, having performed really well in some benchmarks over the past years.

In choosing server software for publicly accessible business applications, I've been wondering whether it would be irresponsible from a security standpoint, to go with server software that might be lacking in ubiquity, such as Nginx.

On the other end of the spectrum, there's Apache with its years of public scrutiny, numerous vulnerabilities that have been fixed and a security team.

Here are my thoughts on the advantages of my two candidate servers that differ hugely in market share, communities and general development environments.

Nginx advantages

  • Ubiquity. It seems to me that the mix of not being too easy a target and being a small player has helped some software products become less likely to be victims of targeted attacks. A good example of this would be Apple's Mac OS X platforms that has seen relatively few attempts compared to Window in the recent past.

    Netcraft server market share figures for June 2009 suggest the comptetitors are running at 4% and 50% of the market for Nginx and Apache, respectively.

  • Smaller codebase, fewer errors. This is just a hypothesis; I haven't viewed either codebase, but assuming a similar code to error ratio, a smaller codebase might lead to less exploits.

    Codebase size, according to Ohloh, is 635:75, the larger one being Apache. I'm not sure whether this includes modules, but given the enormous size delta, it probably does. (That would, of course, lead to a very incorrect conclusion since if security is your focus, you will only be running modules you need.)

Apache advantages

  • Security team. The Apache Software Foundation seems to have quite an advanced security infrastructure.
  • Experience. The Apache HTTP Server projects has seen numerous exploits through the years, and no doubt have they established policies of how best to deal with problems quickly.
  • Ubiquity. This can just as easily be a pro as it could be a con. It means more eyes on the code, but it says nothing of the good eyes to bad eyes ratio.
  • Maturity. As I mentioned earlier, the project has gone through numerous exploits and a lot of public scrutiny.

    This might lead to a slightly lower risk of zero-day exploits because gaping problems are probably less likely to be missed. It might also mean that new exploits would be less critical.

    A quick search did not reveal whether Apache had been subject to a security audit.

  • Documentation. Attack vectors can be created by misconfiguration. This would seem less likely with Apache, as it offers an enormous amount of publications (books and articles alike) of how to secure a server.
  • Number of security modules. From browsing both servers' sites, I have the feeling that Apache outnumbers Nginx in security-enhancing modules by a large margin.

Ubiquity seems to be the double-edged sword. Whether ubiquity is generally good or bad might not be a linear relationship (and probably includes other factors, like whether you're extremely vulnerable to exploits). I highly doubt there's research on ubiquity effects on security vulnerabilities, although I admittedly tried searching.

I probably wouldn't be wondering about this if we were speaking of a social application, a news site or media serving on a server separated from the business application. For an application that deals with payment, personal information and credit card numbers, my current information is leaning towards Apache.

As I'm not a security expert, and my thoughts weren't gathered scientifically and may therefore not be too conclusive, I'd appreciate any input on what factors should influence a decision like this. If nothing else, this remains for the consideration of others in the same position.

  • Is this an actual question; and if so, what is the question? Or are you just a developer on the Nginx team? – George Stocker Jul 3 '09 at 2:39
  • 1
    The question seems to be "I've been wondering whether it would be irresponsible from a security standpoint, to go with server software that might be lacking in ubiquity, such as Nginx." – splattne Jul 3 '09 at 6:41
  • Precisely, splattne. I'm asking if it would be unwise to choose a small player in web servers for business applications and whether anyone has information or knowledge about the security of either solution that could lead to a more scientific conclusion than I've reached in my enumeration. – user11415 Jul 3 '09 at 9:54
  • Post Needs Brevity. – George Stocker Jul 3 '09 at 15:47

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.

| improve this answer | |
  • The only point I'd like to make is that as soon as you've successfully attacked the web server, you have the same access to the application as the web server. If the application has access to sensitive data (through user input or local storage), so does the attacker as jailing only affects what you can do to the system. At any rate, this is a great suggestion. Focusing on security for the servers that process and store sensitive data and still offering some of the performance of Nginx (at some cost) seems like the optimal solution. Thank you for a detailed, articulate and insightful response. – user11415 Jul 9 '09 at 12:14
  • Thanks. Added a part about using nginx as a load balancing HTTP proxy on a separate physical or virtual server, to limit what harm an attack against the nginx instance can do. – Jesper M Jul 9 '09 at 13:54

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.

| improve this answer | |
  • You raise an excellent point regarding the application just being one point of security. However, in a commercial system you should generally seek having all components where weaknesses can exist (network, operating system, web server, application, application libraries) as secure as possible. Having a perfectly secure application won't secure your vulnerable web server. But the problem of knowing what software serves that certainly remains, that the choice seems more based on appearances and human experience than statistics or research. – user11415 Jul 2 '09 at 23:24

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.

| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy