Node/Express security

Question

Im working on my first node application. Now it is ready to deploy and I want secure my application. So I used these libraries to secure it.

import mongoSanitize from 'express-mongo-sanitize';
import helmet from 'helmet';
import xss from 'xss-clean';
import hpp from 'hpp';
import cors from 'cors';
import rateLimit from 'express-rate-limit';

What I want to know is, Am I duplicating things here? Do I have to use all these libraries? Do the libraries here do the same thing so that I can remove them to improve the performance of the app by removing unnecessary middlewares from the app?

• jfriend00: So, you should be using these libraries because you understand what they are doing for you. Therefore, you should have a much more specific question related to two specific libraries overlapping. As it is it seems like perhaps you just grabbed a bunch of libraries related to security and don't really understand what they do. Please ask a more specific question that shows you understand what area each of these libraries covers.
• jfriend00: FYI, the cors library does not "enhance" security. It has a specific purpose to allow cross origin requests when they would otherwise be denied.
• Prabhjot Singh Kainth: You can try using JWT(JSON web tokens),is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

Answer 1

You can't just pile on some "security" library and magically become "secure". Don't you think that if this were possible, all of these packages would be applied automatically, already?

Let's look at what these modules actually do...

express-mongo-sanitize

This module searches for any keys in objects that begin with a $ sign or contain a ., from req.body, req.query or req.params. It can then either:

• completely remove these keys and associated data from the object, or
• replace the prohibited characters with another allowed character.

This is (arguably) a really bad idea. If you were escaping things correctly for use in your queries in the first place, such a sanitizing function wouldn't need to exist. And then, you wouldn't have to worry about a module like this totally wrecking your data structure. Furthermore, if you did rely on this sort of library, you can be sure that there will be some way around it, as it isn't solving the fundamental problem... that mixing the contexts of data and commands is dangerous and error-prone.

helmet

Helmet is a collection of 14 smaller middleware functions that set HTTP response headers.

This package has a whole bunch of stuff, from HSTS to disabling caching. None of them are some sort of security silver bullet, as the author of this package cautions at the very top of the readme file:

It's not a silver bullet, but it can help!

You should understand what all these headers actually do so you can use the right ones. Additionally, much of this you'll want to apply at your web server (such as Nginx) rather than dealing with it in your application.

xss-clean

This will sanitize any data in req.body, req.query, and req.params. You can also access the API directly if you don't want to use as middleware.

Nothing says "security" like an NPM package with near-zero documentation that hasn't been touched in 4 years. It's really an awful idea to begin with though. You should be escaping data for the context of HTML only when you insert that data into HTML. If you do it early, you're just corrupting your data. Misunderstanding of this can actually lead you to future security problems, not to mention a mess of a broken application. (See also: The holy grail of cleaning input and output in php?)

hpp

Express middleware to protect against HTTP Parameter Pollution attacks

This module takes multiple query string variables and prevents them from coming back as an array. This is fine if that's what you want, but having multiple of the same key in the query string is intended, and well-documented behavior that your application can use. If this is a problem, you should actually fix your application rather than relying on this module to break the standard behavior.

cors

As @jfriend00 points out, the CORS library helps you add the appropriate response headers to enable cross-origin access to data. This can be secure and appropriate, but not something you probably want to enable by default.

express-rate-limit

Basic rate-limiting middleware for Express. Use to limit repeated requests to public APIs and/or endpoints such as password reset.

This can be useful, if you want rate limiting. I'd suggest doing this though at the web server level rather than messing with it in your application. There are efficient and fast modules/configurations for Nginx and similar, which are going to be able to handle this better than building it into every Node.js application you build.

TL;DR;

Understand what it is that you're protecting against, or you're absolutely doomed to be insecure no matter what modules you install. Security isn't some patch you install.

• jfriend00: It really seems like the OP should have done their own research on this BEFORE coming here and posting a generic, non-specific question like they did. Instead, you bailed them out and did the research for them. As you are obviously very experienced around here, I would hope you also want to teach people to do their own research before they come here. They, after they do their own research, they can ask a much more specific and meaningful question.
• Shashika Virajh: Thanks Brad. Really appreciate your suggestions.
• Brad: @jfriend00 If I thought that this person could figure it out by simple research, I would have not answered the question in the way I did. Sure, this person could have read the README files, but as indicated in my answer, many of these modules are flawed from the beginning and generally shouldn't be used. I'm addressing the core problem/question (why not [instant security]), pointing out the issues in the various modules listed, and providing myself a question that I can link to in the future. This issue comes up regularly, and the old answer for PHP doesn't apply as often.
• error: @Brad Thank you for your answer which is really usefull for beginners
• error: @jfriend00 Like Brad said, it's not easy to find out all of this by simple research on Google. Hopefully Brad doesn't think like you