Node.js Security: New and cool comes at a cost

04/22/13 23:21:00    

By Michael Mealling

We are evaluating Node.js in a constrained application. Over the past two decades of web evolution there is a standard cycle where new standards, frameworks and languages come into vogue and become popular enough to justify being a target for hacking. J2EE in the 90s lead to the first cross-site scripting attacks, SQL injection, etc. PHP in the 2000s opened web development up to many new developers who had no experience with security. Now, with 'views' moving into the client there is a complete blurring of trust boundaries.

One common blind spot for developers is to assume the attack vector comes through a browser, that you can still trust that browser is still enforcing its rules. But what happens if the browser is the bad guy? Some hear that and assume “oh, he means the hacker is using curl”. No. Assume the other end is a piece of C that is NOT following HTTP 1.1 protocol rules. Run a web application firewall for a few days and you'll see all sorts of things barfed into the open socket on port 80 just trying to trigger various security holes.

Here is some reading material for Node.js advocates to ponder. Trust boundaries matter.

• Node.js Security – Old vulnerabilities in new dresses
• Why Rails and not Sinatra or Node.js?
• Writing secure express.js scripts

So unless you want to end up on the evening news for a security breach, design for not just sad path but evil path.