1

I'm used to writing web stuff in PHP and let Apache or nginx handle the actual HTTP handling and load my code via whatever means (mod_php, fcgi, fpm, ...). I'm under the impression that this is a Good Thing(tm), as there have been years and years of hacking, patching and improving these webservers, so they are "battle tested".

Now, with "newcomers" like Node or Go, I am faced with the question of what's the best way to write real-life, production web applications. I'm hesistant to just let Node listen on port 80, as I fear its HTTP handling mechanism isn't as well tested as that of Apache/nginx (I'm thinking of evil clients, floods, DoS attacks etc.). My admin "confirmed" this by only letting Node apps run behind a reverse-proxy nginx.

Is this fear rational? Or is it totally fine to skip having a dedicated webserver and do the entire request handling in my app (including TLS?)?

3 Answers 3

1

Well-tested code helps to reduce the risk, but even PHP keeps issuing patches to remedy security issues.

The problem is not with "newcomers" but with appropriate protections and controls over any type service that you expose. PHP/Apache/etc. behave (and fail) in predictable ways, but we can predict their behaviours because we have experience with them and know how to respond.

Whether you use the oldest, most maintained codebase on the planet, or your own custom-made product of a "hack-a-thon" weekend, you still need to make sure you have all the appropriate protections in place. From that perspective, your admin's "fear" is perfectly rational: add extra protections around that which you do not fully understand, even if that means you end up being heavy-handed. Then, you can tune, refine, and adjust the controls to an appropriate level.

It's your admin's job to protect the server and the infrastructure so that all services can provide value. It's your job (I'm assuming) to provide a valuable service to the stakeholders and customers. You both need to work together so that everyone can be served.

0

I would not be using node for production but that's a different topic.

The use of ngnix or Apache as a reverse proxy will provide little if no benefit security wise due to the fact that almost everything is being passed through transparently

0
0

I wouldn't use Apache - you won't get much benefit there.

nginx can be used alongside node, as it will serve static files much more efficiently than node can.

Haproxy in front of node can give you better load balancing, rate limiting, than you can get with node.

You can also offload SSL (and SPDY / HTTPv2) to dedicated tools (stunnel, stud) or use modules in haproxy or nginx.

None of this is for security reasons. Just using multiple tools that are individually good at some things to build a system that's good at everything.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .