We are trying to decide which web server to choose for our PHP application.
Which of Apache, nginx or lighttpd is the most secure? Which of these has had the most and most severe security holes?
Add a comment
|
4 Answers
The OS and web server with which you have the most experience are usually going to be the most secure.
Security depends on all of the layers, not just the web server. If you pick one with very few vulnerabilities, but don't understand how to configure it, you will most likely not understand how to configure it securely.
They are all mature web servers, so the one you understand the best is the one you are going to be able to secure the most.
answered Dec 8, 2010 at 21:04
-
6Excellent answer. To elaborate: Apache, nginx, and lighttpd are all high-enough quality that the dominant risk is of configuration error -- you're more likely to get hosed by a configuration mistake than by a bug in the code. This suggests you should focus especially on reducing the likelihood of configuration errors that might cause security breaches. Picking the server that you know best reduces the risk of configuration error.– D.W.Sep 8, 2011 at 19:30
-
8Some people say that the biggest security vulnerability sits at the computer console ;) Dec 26, 2011 at 12:22
-
2@rox0r, This is just avoiding the question, not answering it. This doesn't actually answer the question Which one should you pick if you have equal experience (e.g. zero, or fifty, or hundred) in both servers?– PacerierApr 11, 2016 at 14:08
-
You can't really answer the question. They are all mature web servers. Depending on which features you need out of each web server will tell you which one to use. I know what i prefer, but it seriously depends on what you need the web server to do. Jul 28, 2016 at 18:20
For me the answer to this question is "it depends".
First off I guess it depends on what you mean by secure. If you're looking for freedom from software defects then you could look at vulnerability stats for the products in question from sites like http://www.secunia.com or http://www.cvedetails.com .
from those you could get a view of how many security issues have been publicly acknowledged and patched, which could lead you to say that a product is more or less secure.
Unfortunately not all products get the same level of scrutiny, so that may not be a good measure.
The other thing to consider is security capabilities. If there are specific security capabilities that you require (eg, WAF integration) then that might drive your choice of webserver.
In terms of your specific question, I'd say that Apache has recently had a fairly good security record (most of the vulns I've seen in more up to date versions tend to be in modules not the core server).
As to the others, you could argue that they're secure if there aren't any published vulnerabilities for them, but then they may still have issues that aren't publicly acknowledged.
answered Nov 11, 2010 at 22:15
-
3I would also add that most of the time not the web server is exploited, but the web application running on it. In my opinion one should also take into account ease of configuration, memory/disk consumption, availability of support and not weigh security too high (at least with the better known webservers). Nov 12, 2010 at 13:00
-
1The problem I find is that "past performance is not an indicator of future behaviour", as with investment. Let's say there were 10 critical flaws fixed in Apache last year. Maybe there are none left now. Maybe there are another 100. The metric doesn't tell you.– user185Dec 9, 2010 at 9:04
-
1@graham, yep it's a real problem, to predict future flaw levels. With some projects there seems to be a steady stream of issues, which could indicate a general lack of focus on security, but if you get a high number for a while it could be because of a code clean-up or audit, which is actually a positive sign... Dec 10, 2010 at 10:10
-
1@Graham Lee, it works for insurance companies. Unsafe people are similar to insecure software. But, if they don't tell anyone about the incidents, how would the insurance company know? Sep 8, 2011 at 17:14
-
1@Dogeatcatworld The problem with that analogy is that insurance companies have access to statistics from vast population sizes for any given variable (e.g. a specific age, sex, vehicle model, etc.), so you can form reasonable conclusions based on those variables (e.g. someone of age X is Y% likely to crash their car, because you've got stats on millions of people of that age). It's hard to see how to make software fit into such neat categories and end up with any kind of reasonable population sizes that you could draw accurate conclusions from. Mar 16, 2015 at 21:58
Notwithstanding the recent range header craziness, I think you can make a good case for Apache, if you strip it down to only what you need. mod_security is a nice plus for Apache too.
You should also decide not just based on track record but based on how well you think they'll do going forward. A lot of that is a function of process maturity, state of the codebase, etc. I think Apache does pretty well in general, although like I said, strip it down to only what you need.
Apache has a lot of eyeballs on it, meaning it'll have more bugs reported against it, but remember that just because bugs aren't being reported against a product doesn't mean that they're not there, so if you're targeted in an attack, my opinion is that you want the fewest unknowns possible, and Apache probably wins on that count.
for me , does not matter on apache or nginx or lighttpd , it does matter of staying with updates , install only updated plugins and modules that are weekly/monthly moderated and updated, and the most important is NEVER do a mistake on the web applications (python,perl,php,mysql ,rtmp....) if your apache and its modules are patched/updated , and u have sqli or php buffer overflow so it is useless , and about OS u can make a secured windows server and you can make a vulnreable unix server
source : I am Elite White hacker
http://www.zone-h.org/archive/notifier=k3rnel31
http://www.zone-h.org/archive/notifier=k3rnel31_2
