Node.js Express Framework Security Issues [closed]
I wrote a blog post that gives a great starting point on Writing Secure Express.js Apps. It covers a few other things beyond csrf and helmet as was mentioned by zeMirco.
The other thing is you can't compare express.js to rails. They are apples and oranges. For example, there is no ORM that is bundled with Express, that implementation or use of a third party module is up to you.
I'll try and give a breakdown of each of your concerns.
-Injection Vulnerabilities (JavaScript, SQL, Mongo, HTML)
Again, these are things not built into express. The closest thing would be XSS worries over injection in templates. Jade or EJS templates that are commonly used with express output encode < > " ' and & by default, but remember there are other contexts like user input into JavaScript or CSS that you would need to worry about.
-Session fixation and hijacking
Again see the blog post above, but Express is based on and uses most of the connect middleware one of these is the session middleware. Biggest thing here is to properly set your cookie flags.
-Cross-Site Vulnerabilities (Scripting, Request Forgery)
See above. It also comes with express.csrf() middleware. The blog post mentioned shows how to implement it.
-Mass Assignment
Not an issue with express.js as it has no concepts in which this type of vulnerable would be applicable, however the custom logic you write may be in fact vulnerable to this problem, so again it's a problem of verifying if your code is vulnerable or if the third party module you used is...
Two modules I can immediately think of:
- csrf: CRSF protection middleware.
- helmet: Middleware that implement various security headers
One thing to be wary of is bodyParser. See http://andrewkelley.me/post/do-not-use-bodyparser-with-express-js.html
You should be aware that if you specify a catch-all error handler, you should NOT restart the server or do anything blocking in that handler in response to USER errors (the 4xx range) because it could lead to a DOS vulnerability. This vulnerability is addressed automatically in express-error-handler, and the service will shut down as soon as it can (when active connections are drained or a timeout occurs) so restarts shouldn't be a big deal. Implementing this behavior made a really big difference in my exploit tests.
BTW, it's NOT safe to simply ignore all unhandled errors. That would leave your application in an undefined state, which just presents another type of DOS vulnerability.